Re: proposal for issue #178

mån 2010-05-17 klockan 07:37 -0400 skrev Yves Lafon:
> On Sun, 9 May 2010, Henrik Nordström wrote:
> 
> > ons 2010-03-24 klockan 20:47 -0400 skrev Yves Lafon:
> >
> >>     If the 206 response is the result of an If-Range request, the
> >>     response SHOULD NOT include other entity-headers.  Otherwise, the
> >>     response MUST include all of the entity-headers that would have been
> >>     returned with a 200 (OK) response to the same request, except for
> >>     Content-MD5 that MUST NOT be present.
> >
> > For compatibility reasons this can not be a MUST NOT, only a SHOULD NOT.
> >
> >>     Recipients MUST ignore Content-MD5 on 206 responses; Caches MUST strip
> >>     Content-MD5 when caching or combining 206 responses with existing
> >>     cached content.
> >
> > Same here.
> 
> Issue with a SHOULD NOT is that Content-MD5 may be present, and in that 
> case we have a real interoperability issue. It is one of the few areas 
> where we need to break compatibility (but as not that many servers are 
> sending Content-MD5, and even less for Content-MD5 for 206 responses, it 
> is quite unlikely that it will break implementations)


I am OK with the client side SHOULD NOT requirement. As you say the
likelyhood of breaking any existing implementations is very slim there.

But not sure about the server side. For one thing there is is existing
server implementations of both alternatives for how to generate
Content-MD5 in partial responses, MD5(partial entity-body) or MD5(full
entity-body). Also having this requirement on servers complicates server
implementations even more.

If we are to break server implementations then I would very much prefer
the specs clarify which of the two should be used, and my preference
there is clearly for MD5(full entity-body).

Is there any other known servers than older Jigsaw versions which
implements Content-MD5 as MD5(partial entity-body)?

I ask this because I see an alternative resolution to this problem by
defining Content-MD5 as MD5(full entity-body), and instead of ignoring
Content-MD5 in partial responses requiring clients to NOT merge 206
responses with conflicting Content-MD5, and instead if needed retry the
request without the Range specifier. 

But I do not really have a strong opinion on this. Any change is to the
better, including moving Content-MD5 as a whole to historic noting that
it SHOULD NOT be used by either servers or clients in this
specification. There exists a standards track alternative to Content-MD5
ready to replace it, it's not used much, and have conflicting
implementations.

Regards
Henrik

Received on Monday, 17 May 2010 13:05:40 UTC