[OASIS Issue Tracker] Updated: (ODATA-419) Specify ETag handling more precisely

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ODATA-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-419:
-----------------------------

       Proposal: 
Recommend using weak ETags and refer to HTTPbis for the new semantics of weak ETags with If-Match

Align ETag-related sections "8.3.1 ETag Header", "8.2.3 Header If-Match", "8.2.4 Header If-Non-Match" and "11.4.1.1 Use of ETags for Avoiding Update Conflicts" with HTTPbis.
    Environment: [Proposed]

ETags: Weak or Strong
- Strong ETag: byte-for-byte identical, i.e. Atom and JSON representations would need different ETags
- Weak ETag: semantically identical, e.g. Atom and JSON representations, content-language, ignoring computed properties, ...

Preference: weak ETag, same ETag for Atom and JSON, independent of content language, ignoring computed properties.

Problem:  RFC2616, section 14.24 If-Match states
- A server MUST use the strong comparison function (see section 13.3.3) to compare the entity tags in If-Match.
	
And RFC2616, section 13.2.2 Weak and Strong Validators states
- The strong comparison function: in order to be considered equal, both validators MUST be identical in every way, and both MUST NOT be weak.

So if we use weak ETags, If-Match with RFC2616 (HTTP/1.1) semantics would never consider them equal.

This seems to be a bug in RFC2616 as HTTPbis (http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-22#section-3.1) states
- The If-Match condition is met if and only if any of the entity-tags listed in the If-Match field value match the entity-tag of the selected representation using the weak comparison function (as per Section 2.3.2), or if "*" is given and any current representation exists for the target resource.


> Specify ETag handling more precisely
> ------------------------------------
>
>                 Key: ODATA-419
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-419
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol 
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD02
>
>
> The specification should be more specific about the ETag handling. E.g. should a weak or strong ETag be generated on the server? 
> This has consequences because [RFC-2616] (chapters 13.3, 14.24 and 14.26) seem to define the ETag handling slightly different than in this spec.
> This affects sections "8.3.1 ETag Header", "8.2.3 Header If-Match", "8.2.4 Header If-Non-Match" and "11.4.1.1 Use of ETags for Avoiding Update Conflicts".
> Also state whether we expect ETags for collections that advertise actions, or whether we expect the advertised action to contain an action-specific ETag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira