Re: proposal for issue #178

On Mon, 17 May 2010, Henrik Nordström wrote:

> 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.

I agree that those are the two major options, forbid the use of C-MD5 in 
206, or explicitely say that it is only about the full content, but will 
defeat the purpose of acting as a message integrity check...

Forbidding its use is the safe side, as there are known implementation 
issues (but not widely visible, as C-MD5 is not used that much anyway).

> 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
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 3 June 2010 17:08:32 UTC