Re: Comments on draft-dusseault-http-patch-06

On Oct 17, 2004, at 10:45 PM, Roy T. Fielding wrote:

> On Oct 17, 2004, at 3:52 PM, Lisa Dusseault wrote:
>> Jeffrey Mogul suggested this change from the -05 model; I think it 
>> works at least as well as the model where the request body is 
>> modelled as an instance.  It's entirely consistent with RFC3229's 
>> model.  And instead of using the IANA MIME type registry, it uses the 
>> IANA instance-manipulation registry.  Do you have any technical 
>> objections to using the IM header and the instance-manipulation 
>> values?
>
> I already gave my technical objections.

I've searched through the earlier mail I'd cached from you on this 
topic, can you point out which are the technical objections?  It's been 
my impression that there are duelling theories of HTTP here, and most 
of the arguments were theoretical.  One of the duelling theories may be 
revisionist; one of those theories may better match what the original 
authors had in mind; I don't know.  Personally I'm more interested in 
what works better, partly for PATCH in specific and partly for HTTP 
extensibility in general.

> HTTP doesn't allow it.  You
> can't just redefine the messaging model of HTTP (and, in this case,
> MIME) while defining a method.

Why is this redefining MIME?  I understand how it's a different 
messaging model of HTTP from the one you prefer, but I don't understand 
how it redefines MIME.  As I understand it, RFC3229 uses MIME types to 
describe the entity or instance without redefining MIME.

As for redefining the messaging model of HTTP: RFC2616 has other 
headers that refer to the entity or the instance, and not to the 
message body.  For example, "The MD5 digest is computed based on the 
content of the entity-body, including any content-coding that has been 
applied, but not including any transfer-encoding applied to the 
message-body."   That means that Content-MD5 is calculated from what 
RFC3229 labels an "instance".  It seems to me that RFC3229 only defined 
a name, "instance", for something which already existed.

I do realize that RFC2616 is ambiguous, and I don't mean to justify one 
theory based on legalistic readings of the spec.  On the one hand, 
RFC2616 says "Content-Type specifies the media type of the underlying 
data.".  On the other hand, RFC2616 says "Any HTTP/1.1 message 
containing an entity-body SHOULD include a Content-Type header field 
defining the media type of that body."  Both these sentences are in 
section 7.2.1! The first sentence seems to support RFC3229's model; the 
second sentence seems to support your (Roy's) preferred model.  
Standards are rarely perfect; ambiguous language like this leaves lots 
of room for interpretation of how the model can be refined and how HTTP 
can be extended.  So I tend to devalue arguments based only on selected 
text from the standard; I'd like to hear more arguments based on 
harmful intermediary interactions or implementation concerns.


> There is no way to do that in HTTP
> because there is no way to check that all servers between the client
> and the origin are aware of this abuse before sending the message,
> nor is there any technical reason for redefining an existing header
> field to mean something other than what is in two Draft Standards.

I'm definitely sympathetic to concerns about intermediaries (that's why 
I'm doing PATCH -- because I'm worried about the way XCAP is redefining 
PUT and GET).  However, I don't yet understand what an intermediary 
might do with a new method it hasn't seen before (PATCH) that has a 
header it has seen before (Content-Type) that could be harmful.  An 
intermediary can't cache the body of a method it hasn't seen before 
(e.g. PROPPATCH request and response bodies are similarly uncached in 
practice).  An intermediary can apply transfer-encodings but I don't 
see how that could be harmful.  For example, an intermediary could 
apply chunked transfer encoding to a PATCH body in either the PATCH -05 
proposal or the PATCH -06 proposal without harm.  Or am I missing 
something?  What else can an intermediary do and how might it be 
harmful?

I did realize one advantage of the PATCH with IM approach, and that is 
to create a new resource of a specified type.  For example:

        PATCH /file.ics HTTP/1.1
        Host: www.example.com
        Content-Type: text/calendar;component=VEVENT
        IM: vcdiff
        If-Match: "e0023aa4e"
        Content-Length: 100

        [vcdiff-bytes]

 >>Response:

        HTTP/1.1 201 Created
        ...

This would create a new file of type text/calendar.  With the PATCH -05 
proposal, there wasn't a way to use PATCH to create a new resource and 
assign the correct MIME type to begin with.

So what's the consensus here or do we need more light on these issues 
before we can reach a consensus?  Do any implementors have 
implementation considerations related to this issue, and are there 
realistic intermediary problems as I already asked?  How much of a 
religious war is it?    I'm not personally religious on this, I'm 
caught between the duelling theories and I'd just like to understand 
the practical considerations better.

Lisa

Received on Monday, 18 October 2004 17:22:07 UTC