[ietf-http-wg] <none>

Sorry if I bring up an old subject, but it's still not resolved in
2616..

There obviously is some serious confusion regarding what the term for
the body of a 206 response really is.

I think the only possible correct reading of the RFC is that the body of
a 206 response carries the indicated ranges of the corresponding 200
response entity-body for the same request, and that it is not an
entity-body on it's own.

But others clearly disagree, and we even have a standards track RFC 3230
claiming otherwise.

It's mainly of importance for the Content-MD5 header. Is it an entity
header from the 200 response, or a property of the 206 message response
body?

If Content-MD5 is a property of the 206 message (sans transfer encoding)
then if must be explicitly excluded in 13.5.4, preventing it from being
copied over to the merged entity. And should also be mentioned 10.2.7
preventing caches from echoing the header when constructing 206
responses from a cached entity.

If it's a entity header from the 200 respone entity then this should be
clarified somehow and an errata for RFC3230 filed preventing it from
reaching Proposed Standard without first removing that claim.


Have read 2616 many times now, and each time I only see more evidence
that the 206 response is indeed special, not carrying an entity as such
only fragments of the 200 response entity and that Content-MD5 is of the
full 200 response entity, not the message. And less support for the view
expressed in RFC3230. 


Some of the possible paths ending up in the different views

Content-MD5 entity header -> enity-body -> message body -> 206 not
defined to have a different message body so it's the entity-body for
Content-MD5.

206 -> 200 ok entity headers -> content-md5 is a entity entity header,
so it's the 200 ok that is the entity. 206 response does not have an
entity-body as such.


206 generated from cache -> 200 OK is the entity-body. 206 response does
not have an entity body as such.

merging of partial 206 responses -> Contetn-MD5 not excluded -> 200 OK
is the entity-body.

content-range -> distinction of full/partial entity-body. 200 ok is
probably the entity-body elsewhere in the document.

partial get -> part of the entity -> 200 ok is the entity body. 



The fact that RFC3230 has been accepted as standards track after 2616 is
alone sufficient indication that this needs to be clarified further.


The simplest change is to change the first paragraph of Content-MD5 to
refer to the full entity-body instead of just entity-body, and leave the
rest as it is.

It's also possible to clearly define Content-MD5 as applying to this
response only if it really should be a message property and not a
property of the full entity-body, but this requires a lot more changes
to both make sure partial responses generated from a cache does not echo
the Content-MD5 of the full response, and that merged responses do not
copy the Content-MD5 from a partial response.

Another option is to drop the directive as "unfixable". It's not of any
widespread use. And perhaps refer to RFC3230 instead which is even less
deployed.

In my eyes Content-MD5 of the full entity-body it's a very good
integrity check, both for full GETs and when merging ranges of partial
responses, so having Contetn-MD5 clearly defined as being of the full
entity-body makes a lot more sense to me.

I see it's use as per-message integrity check less useful. Partial
responses exists for many reasons, not only 206 responses. And in most
cases the partial response alone isn't very useful without being
completed with the missing pieces first.

Regards
Henrik