OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (ODATA-1096) 9.1.4 Response Code 204 No Content: rephrase second paragraph

    [ https://issues.oasis-open.org/browse/ODATA-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66987#comment-66987 ] 

Martin Zurmuehl commented on ODATA-1096:

The intention of the qoute from RFC7231 in section 9.4.1 is expressed by Julian Reschke  (one of the 
editors of RFC7231): "The main point here is that the server can only return an Etag if what was stored actually is what the client sent. If the server modified the data, the client will have to fetch the content using a subsequent GET request."
Source: First comment to the question at https://stackoverflow.com/questions/42246577/why-responses-to-put-requests-must-not-provide-an-etag.

> 9.1.4 Response Code 204 No Content: rephrase second paragraph
> -------------------------------------------------------------
>                 Key: ODATA-1096
>                 URL: https://issues.oasis-open.org/browse/ODATA-1096
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: Protocol
>    Affects Versions: V4.01_CSD02
>         Environment: Non-material
>            Reporter: Ralf Handl
>             Fix For: V4.01_CS01
> The second paragraph of section 9.1.4 is a quote from RFC7231 and somewhat hard to parse. Replace it with text that expresses its intention: send an ETag only if the client can reasonably "know" the current entity representation that has not been sent in the response:
> (1) For a PUT request: if the response body of a corresponding 200 response would have been identical to the request body, i.e. no server-side modification of values sent in the request body, no "calculated" values. 
> (2) We could extend this to PATCH requests and if a corresponding 200 response would have consisted of
> - values sent in PATCH request body, plus 
> - server-side values corresponding to ETag sent in If-Match header of PATCH request (for values not sent in PATCH request body)

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]