Subject: Re: PATCH thoughts...

From: Lisa Dusseault <[email-masked]>
Date: Fri, 30 Apr 2004 14:03:51 -0700

I originally thought all HTTP messages with bodies needed to indicate 
Content-Type.
I assumed that if the Content-Type header were used then that was the
obvious place to say what diff format is being provided.  Thus PATCH
has currently:

     PATCH /file.txt HTTP/1.1
     Host: www.example.com
     Content-Type: application/gdiff
     If-Match: "e0023aa4e"
     Content-Length: 100

    [body]

However, clearly RFC3229 doesn't take that approach -- some responses 
are
shown with bodies (implied) but with only a Content-encoding header to 
indicate
that there's even a body on the message.  Modelling on the RFC3229 
approach,
PATCH could look like this instead:

       PATCH /file.txt HTTP/1.1
       Host: foo
       If-Match: "def"
       Content-encoding: gzip
       IM: vcdiff

     [body]

Now that I've reviewed this part of 2616 more carefully, it seems 
RFC32229
takes a justified approach.  RFC2616, section 7.2.1 only requires 
Content-Type
for entity bodies, not for other non-entity request bodies:

    When an entity-body is included with a message, the data type of that
    body is determined via the header fields Content-Type and Content-
    Encoding.

WebDAV seems to have interpreted this requirement more broadly,
as if it were worded  "When a body is included with a message, ..."
For example, PROPFIND requests contain a body that is not an entity 
body,
but instead additional command detail.  Since the body must be XML, each
PROPFIND request has the "Content-Type: application/xml" header.
Implementors also seem to have interpreted this requirement broadly.
I know of server implementations that do not expect to see a message 
body
if the Content-Type header is missing and they interpret the body, if 
sent,
as the next request.

One compromise is to inlude Content-Type with a reasonably appropriate
MIME type, but one that doesn't need to specify the diff format used.

       PATCH /file.txt HTTP/1.1
       Host: foo
       If-Match: "def"
       Content-encoding: gzip
       IM: gdiff
       Content-Type: application/octet-stream

     ...

This certainly routes around the MIME registration issue and may be
preferable.  I have no strong opinions on that.

Lisa

On Apr 30, 2004, at 1:34 PM, Jeffrey Mogul wrote:

>     So please voice your opinions on this issue to help me off this 
> fence.
>     Should PATCH require support for one diff format, and if so, what?
>     Should it use MIME types or strings to identify diff formats?  
> Should
>     it register MIME types for VCDiff and/or GDiff (ouch)?
>
> Please bear with me if I'm just being ignorant ... I haven't read
> much of the WebDAV spec, especially not within the last couple
> of years (and I certainly don't have time to read it now).
>
> But why should this be a MIME type at all?  HTTP has a clear
> distinction between MIME _content_ types (I emphasize the
> word _content_ here) and several _separate_ name spaces for
> representations used for on-the-wire encodings.  These
> include content-codings and content-transfer-codings in
> RFC2616, and RFC3229 introduces "instance-manipulations"
> as a third (orthogonal) space.
>
> I can assure you that we did not do this just to make more
> work for IANA.
>
> I can anticipate an argument along the form of "why create
> a new namespace when an existing one is almost the right
> thing?".  This is very dangerous; "almost the right thing"
> can lead to extremely messy workarounds.
>
> For example, with delta encoding, our original thought
> was that this is "obviously just a new content-coding".
> We then spent months thrashing around how to deal with
> all of the resultant complexity that arises when you try
> to do this and compose delta encoding with things like
> compression and byte ranges.  It was only after the "aha"
> that delta encoding was NOT the same as a content-coding
> that we came up with a clear, clean design.
>
> There's some rationale for this in RFC3229, and some more
> in my WWW 2002 paper (http://www2002.org/CDROM/refereed/444.pdf)
>
> -Jeff

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 30 Apr 2004 22:39:44 +0100

Lisa Dusseault wrote:
> body if the Content-Type header is missing and they interpret the
> body, if sent, as the next request.

That's a big fat bug.  They should check the Transfer-Encoding and
Content-Length headers: if either exist, there's a body.
Transfer-Encoding has precedence.  If neither exist, there's a body if
Content-Type is multipart/byteranges.

See "4.4 Message Length" in RFC2616.

-- Jamie

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 30 Apr 2004 14:44:05 -0700

Sure, it's a big fat bug.  Just saying that I'm not the only one who 
assumed
that every HTTP message with a body had a Content-Type.

lisa

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 Apr 2004 15:55:41 -0600 (MDT)

On Fri, 30 Apr 2004, Lisa Dusseault wrote:

> RFC2616, section 7.2.1 only requires Content-Type for entity bodies,
> not for other non-entity request bodies:
>

The above is not really a requirement. Content-Type is not a REQUIRED
header. Content-Encoding is only needed for encoded content. The
presence and transfer-length of request body is determined according
to these rules (see Section 4.4 for details, subject to errata):

   2.If a Transfer-Encoding header field (section 14.41) is present
     ... then the transfer-length is
     defined by use of the "chunked" transfer-coding (section 3.6)

   3.If a Content-Length header field (section 14.13) is present, its
     decimal value in OCTETs represents both the entity-length and the
     transfer-length.

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MUST NOT be included in
   a request if the specification of the request method (section 5.1.1)
   does not allow sending an entity-body in requests. A server SHOULD
   read and forward a message-body on any request; if the request method
   does not include defined semantics for an entity-body, then the
   message-body SHOULD be ignored when handling the request.

There are other related MUSTs.

> WebDAV seems to have interpreted this requirement more broadly, as
> if it were worded "When a body is included with a message, ..." For
> example, PROPFIND requests contain a body that is not an entity
> body, but instead additional command detail.

IMO, any body is "entity body" from HTTP point of view. There are just
different entities being embodied.

> One compromise is to include Content-Type with a reasonably
> appropriate MIME type, but one that doesn't need to specify the diff
> format used.
>
>        PATCH /file.txt HTTP/1.1
>        Host: foo
>        If-Match: "def"
>        Content-encoding: gzip
>        IM: gdiff

As far as I can see, the above request will not be handled correctly
by intermediaries (they will drop its body). You need either
Content-Length or Transfer-Encoding header.

HTH,

Alex.

---

From: Jeffrey Mogul <[email-masked]>
Date: Fri, 30 Apr 2004 15:23:53 -0700

I originally thought all HTTP messages with bodies needed to
    indicate Content-Type.  I assumed that if the Content-Type header
    were used then that was the obvious place to say what diff format
    is being provided.  Thus PATCH has currently:
    
	 PATCH /file.txt HTTP/1.1
	 Host: www.example.com
    
	[body]
    
    However, clearly RFC3229 doesn't take that approach -- some
    responses are shown with bodies (implied) but with only a
    Content-encoding header to indicate that there's even a body on the
    message.

Note that the examples in RFC3229 were meant to be barely-legal
HTTP, not necessarily including all of the header fields that
one might actually want to send.

In any case, the example responses in RFC3229 are for delta-encoded
results that are meant to be applied to an *existing* cache entry.
Therefore, the Content-type of that cache entry defines the
content type of the updated instance.  (In theory, I suppose,
the update could change the content-type of the original ...
that is, you could start with an image/gif and update via a
delta to an image/jpeg, in which case the delta-encoded response
would indeed require a Content-type header.  But somehow this
feels like a ghastly thing to do!)

Remember also that "Content-Type" really is a property of the
underlying resource, rather than of the response message per se.
RFC2616 uses poor terminology in almost all the places where
it matters for this issue, but there's a statement in 7.2.1:

   Content-Type specifies the media type of the underlying data.

as opposed to the "additional content codings applied to the data".

    Modelling on the RFC3229 approach, PATCH could look like
    this instead:
    
	   PATCH /file.txt HTTP/1.1
	   Host: foo
	   If-Match: "def"
	   Content-encoding: gzip
	   IM: vcdiff
    
           [body]

Seems reasonable to me :-)

	   PATCH /file.txt HTTP/1.1
	   Host: foo
	   If-Match: "def"
	   Content-encoding: gzip
	   IM: gdiff
    
That's actually a good idea -- then the server can check to
make sure that the client's idea of the resource's content-type
is consistent with the server's idea.

-Jeff

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 Apr 2004 16:10:05 -0600 (MDT)

On Fri, 30 Apr 2004, Lisa Dusseault wrote:

> So is it your opinion that Content-Type is required on any HTTP
> request that has a body?

No, it is not my opinion. Content-Type is a RECOMMENDED not REQUIRED
header.

According to RFC 2616, the presence or absence of Content-Type header
does not indicate presence or absence of request body (there is a gray
area of multipart/byteranges codings, but let's ignore that). A client
SHOULD send Content-Type header if request has a body.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 Apr 2004 16:02:17 -0600 (MDT)

On Fri, 30 Apr 2004, Jamie Lokier wrote:

> They should check the Transfer-Encoding and Content-Length headers:
> if either exist, there's a body. Transfer-Encoding has precedence.

Yes, and _only_ those headers.

> If neither exist, there's a body if Content-Type is
> multipart/byteranges.

Sending a multipart/byteranges request is, in general, a violation of
the following MUST NOT:

   This media type
   UST NOT be used unless the sender knows that the recipient can arse
   it

That is why, I guess, RFC 2616 goes on to say, explicitly (but
informally):

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers.

Many (most?) implementations cannot handle requests with bodies except
for PUT and POST, especially if the body is chunked.

Alex.

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 30 Apr 2004 15:01:34 -0700

I'm not quite sure I follow, comments inline...

> different entities being embodied.

So is it your opinion that Content-Type is required on any HTTP request
that has a body?  If not, then I'm misunderstanding.

> Content-Length or Transfer-Encoding header.

I didn't intend to omit that.    This example should have one of those.
The other examples should as well.