Hi,
we've been discussing the interpretation of ETags returned upon an HTTP
PUT request for some time now. Jim Whitehead started work on an Internet
Draft discussing this topic in February (see
<>),
but unfortunately we didn't make any progress since.
Personally, I think that we really need a very minor clarification, plus
a simple new feature to help clients that want to avoid a re-fetch after
sending the content. I therefore decided to write up my own draft. It
summarizes the situation (as RFC2616 is concerned), proposes one
clarification to RFC2616 (as mentioned in
<>),
and also proposes that minor new feature (a new response header).
Feedback appreciated. I mean it. We really should resolve this, as two
drafts in front of the IESG already make contradicting requirements.
HTML at
<>.
Best regards, Julian
Internet-Drafts (AT) ietf (DOT) org schrieb:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title: The Hypertext Transfer Protocol (HTTP) Entity Tag (^ETag^) Response Header in Write
Author(s): J. Reschke
Filename:
Pages: 19
Date: 2006-8-9
The Hypertext Transfer Protocol (HTTP) specifies a state identifier,
called "Entity Tag", to be returned in the "ETag" response header.
However, the description of this header for write operations such as
PUT is incomplete, and has caused confusion among developers and
protocol designers, and potentially interoperability problems.
This document explains the problem in detail and suggests both a
clarification for a revision to the HTTP/1.1 specification (RFC2616)
and a new response header, making HTTP entity tags more useful for
user agents that want to avoid round-trips to the server after
modifying a resource.
A URL for this Internet-Draft is:
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request (AT) ietf (DOT) org with the word unsubscribe in the body of the message.
You can also visit
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get ".
A list of Internet-Drafts directories can be found in
or
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv (AT) ietf (DOT) org.
In the body type:
"FILE /".
NTE:The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCDING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
I-D-Announce mailing list
I-D-Announce (AT) ietf (DOT) org

Hi Julian,

Julian Reschke a :

Hi,

we've been discussing the interpretation of ETags returned upon an
HTTP PUT request for some time now. Jim Whitehead started work on an
Internet Draft discussing this topic in February (see
<>),
but unfortunately we didn't make any progress since.

Personally, I think that we really need a very minor clarification,
plus a simple new feature to help clients that want to avoid a
re-fetch after sending the content. I therefore decided to write up my
own draft. It summarizes the situation (as RFC2616 is concerned),
proposes one clarification to RFC2616 (as mentioned in
<>),
and also proposes that minor new feature (a new response header).

Feedback appreciated. I mean it. We really should resolve this, as two
drafts in front of the IESG already make contradicting requirements.

HTML at
<>.
--
I'm not sure the Entity-Transform header is needed since you might as
well achieve the same result by using both the status code and the
content type of the returned entity.

Server does not modify the resource =Sends a 204 No Content
Server does modify the resource =Sends a 200 and the newly created
entity with its new media-type.

That way the user agent knows if the resource has been modified and how.
- Sylvain

Sylvain Hellegouarch schrieb:
I'm not sure the Entity-Transform header is needed since you might as
well achieve the same result by using both the status code and the
content type of the returned entity.

Server does not modify the resource =Sends a 204 No Content
Server does modify the resource =Sends a 200 and the newly created
entity with its new media-type.

That way the user agent knows if the resource has been modified and how.

Specifying that behavior would be incompatible with RFC2616, which
already allows a server to rewrite the content without returning it in
the response body.

And, as Cyrus pointed out, returning the new body is expensive, and most
of the times completely useless (which I tried to demonstrate in
<#simple.authoring>).
To optimize the case where the client indeed *wants* the new content, we
would need a new way to signal that, such as a new request header
(feedback appreciated).

Best regards, Julian

Sylvain Hellegouarch schrieb:
>I'm not sure the Entity-Transform header is needed since you might as
>well achieve the same result by using both the status code and the
>content type of the returned entity.
>>
>Server does not modify the resource =Sends a 204 No Content
>Server does modify the resource =Sends a 200 and the newly created
>entity with its new media-type.
>>
>That way the user agent knows if the resource has been modified and how.
>
Specifying that behavior would be incompatible with RFC2616, which
already allows a server to rewrite the content without returning it in
the response body.

And, as Cyrus pointed out, returning the new body is expensive, and most
of the times completely useless (which I tried to demonstrate in
<#simple.authoring>).
To optimize the case where the client indeed *wants* the new content, we
would need a new way to signal that, such as a new request header
(feedback appreciated).

Both are fair points. I am still not convinced by the way Entity-Tranform
is specified though. It seems over complicated. Why not defining the
Entity-Transform header has follow:

Entity-Transform = "Entity-Transform" ":" media-type

Thus taking benefit from the existing IANA registration for what you call
token in your proposal of the header. At least in that case the user-agent
would know precisely how the server has transformed the request entity and
the impact of that extension would be minimum.
If the header was not present in the response it would mean the server did
not transform the entity.
- Sylvain

Sylvain Hellegouarch schrieb:
Both are fair points. I am still not convinced by the way Entity-Tranform
is specified though. It seems over complicated. Why not defining the

Well, that's why I was submitting a draft -- feedback is needed. I
realize that Entity-Transform currently may violate the KISS principle,
maybe I should go back to it's minimal form of:

Entity-Transform = "Entity-Transform" ":" 1#transform-info
transform-info = "identity" | "unspecified"

and leave everything else to future specs.

Entity-Transform header has follow:

Entity-Transform = "Entity-Transform" ":" media-type

Thus taking benefit from the existing IANA registration for what you call
token in your proposal of the header. At least in that case the user-agent
would know precisely how the server has transformed the request entity and
the impact of that extension would be minimum.

Reusing media types sounds like a good idea, but I'm not sure how this
is going to work. Could you give examples for some of the use cases
mentioned in the document (XML Infoset preserved, HTML filtering, SVN
keyword substitution, AtomPub)?

If the header was not present in the response it would mean the server did
not transform the entity.

We can't do that, because it's incompatible to RFC2616 (as reasoned in
<#rfc.section.1.3
-- if people feel I got this one wrong by all means speak up :-))

Best regards, Julian

Sylvain Hellegouarch schrieb:
>Both are fair points. I am still not convinced by the way
>Entity-Tranform
>is specified though. It seems over complicated. Why not defining the
>
Well, that's why I was submitting a draft -- feedback is needed. I
realize that Entity-Transform currently may violate the KISS principle,
maybe I should go back to it's minimal form of:

Entity-Transform = "Entity-Transform" ":" 1#transform-info
transform-info = "identity" | "unspecified"

+1

and leave everything else to future specs.
>
>Entity-Transform header has follow:
>>
>Entity-Transform = "Entity-Transform" ":" media-type
>>
>Thus taking benefit from the existing IANA registration for what you
>call
>token in your proposal of the header. At least in that case the
>user-agent
>would know precisely how the server has transformed the request entity
>and
>the impact of that extension would be minimum.
>
Reusing media types sounds like a good idea, but I'm not sure how this
is going to work. Could you give examples for some of the use cases
mentioned in the document (XML Infoset preserved, HTML filtering, SVN
keyword substitution, AtomPub)?

Fair point. I had not thought this through. In that case I think your
above proposal is a good one.
- Sylvain

Sylvain Hellegouarch schrieb:
>Sylvain Hellegouarch schrieb:
Both are fair points. I am still not convinced by the way
Entity-Tranform
is specified though. It seems over complicated. Why not defining the
>Well, that's why I was submitting a draft -- feedback is needed. I
>realize that Entity-Transform currently may violate the KISS principle,
>maybe I should go back to it's minimal form of:
>>
>Entity-Transform = "Entity-Transform" ":" 1#transform-info
>transform-info = "identity" | "unspecified"

+1

Hmm, I think this would still need to be

transform-info = "identity" | "unspecified" | extension
extension = token

so it *can* be extended later.

More feedback appreciated Do people think it's worthwhile for a
server to be able to specify the kind of transform?

Best regards, Julian

Aug 9, 2006, at 1:32 PM, Julian Reschke wrote:

Personally, I think that we really need a very minor clarification,
plus a simple new feature to help clients that want to avoid a re-
fetch after sending the content. I therefore decided to write up my
own draft. It summarizes the situation (as RFC2616 is concerned),
proposes one clarification to RFC2616 (as mentioned in <http://
>),
and also proposes that minor new feature (a new response header).

No thanks. A new response header will just be interpreted as an entity
header. The easier solution is to simply require that ETag in a
response
to PUT means that the client can use that entity tag in future
conditional
requests. How the server manages to accomplish that feat if it isn't
storing things octet-for-octet is none of your business.

Note that this will solve your problem without requiring that the server
become a filesystem, and is also consistent with XCAP (even though XCAP
is a really bad use of HTTP). In spite of the overspecification in
CALDAV,
the implementation will work fine as well for the above case.

Roy

Roy T. Fielding wrote:
Aug 9, 2006, at 1:32 PM, Julian Reschke wrote:

>Personally, I think that we really need a very minor clarification,
>plus a simple new feature to help clients that want to avoid a
>re-fetch after sending the content. I therefore decided to write up my
>own draft. It summarizes the situation (as RFC2616 is concerned),
>proposes one clarification to RFC2616 (as mentioned in
><>),
>and also proposes that minor new feature (a new response header).

No thanks. A new response header will just be interpreted as an entity
header

That's correct, although I'm not sure how bad that is in practice.

First of all, if we restrict this for usage in PUT, intermediates
shouldn't be a problem because
<#rfc.section.9.6.p.2says
that responses to PUT aren't cacheable.

As far as the user agent itself is concerned, we can make sure that it
knows about that header by making this an opt-in behavior. I thought we
could avoid having a new request header as well, but if this is really
required, we could do that.

The easier solution is to simply require that ETag in a response
to PUT means that the client can use that entity tag in future conditional
requests

The basic question I'd like to see answered is whether clients - as per
RFC2616 - can rely on an ETag being usable in conditional byte range
requests. I think they can't (as the ETag is for what was stored, not
what was sent), thus the attempt to make that piece of information
available to the client.

How the server manages to accomplish that feat if it isn't
storing things octet-for-octet is none of your business.

As demonstrated in the draft, in general conditional requests will work
just fine. Problems only can occur when the client assumes it knows the
exact content, for instance for a PUT with byte range.

K, here's a thought: When a server wants to return an entity tag upon
PUT (or related messages), and a transform did occur, it can return an
ETag that is marked as "transformed content". That ETag will be usable
for any operation that doesn't require octet-by-octet identity. For
instance:

C1: PUT /x HTTP/1.1
Host: example.com
Content-Type: text/plain

T

S1: HTTP/1.1 201 Created
ETag: "01234-temp"

(temporary etag assigned)

C2: PUT /x HTTP/1.1
Host: example.com
If-Match: "01234-temp"
Content-Type: text/plain

TestTwo

S2: HTTP/1.1 200 K
ETag: "01235-temp"

(validation ok, new temporary etag assigned)

C3: PUT /x HTTP/1.1
Host: example.com
If-Match: "01235-temp"
Content-Type: text/plain
Range: bytes=5,

Three

S3: HTTP/1.1 412 Precondition Failed
ETag: "01235"

(validation fails because octet-by-octet equality is required, so server
says 412 and returns the final Etag).

Would that work? And even if it does, are user agents allowed to assume
that every server works that way (I think no, they can't, but that's the
issue I'd like to see resolved).

(And yes, I'm aware of weak etags, but
<#rfc.section.14.24
requires the strong comparison for If-Match, so they don't seem to be
usable here).

Note that this will solve your problem without requiring that the server
become a filesystem, and is also consistent with XCAP (even though XCAP
is a really bad use of HTTP). In spite of the overspecification in CALDAV,
the implementation will work fine as well for the above case.

Right now (and in the case of servers rewriting the content upon PUT),
CALDAV disallows returning a strong ETag, while XCAP requires it. I
really think that's a problem, so I think at least one of the two needs
to be changed before it can be published on the standards track. I'm
note sure we are in agreement here. Are we?

Best regards, Julian