Re: 206 and extra headers

On Sat, Jun 5, 2010 at 7:10 AM, Yves Lafon <ylafon@w3.org> wrote:
> During the last f2f, we noodled around the idea of adding some
> meta-information to do bytes to units conversion.
> I encourage you to read section 10.2.7 of RFC2616.
>
> Basically, if we retrieved first part of the media entity (to get
> informations needed to decode the data), we should use an If-Range to
> ensure we are handling the same content, and it forbid the use of another
> header. Also adding an entity header in a non-If-Range tells a bad story for
> caches.
>
> So the best course of action if we decide to add equivalence directly in the
> reply would be be to add it in the Content-Range definition for those units.


I'm going to have to step back and try and understand this from the
ground up. This explanation is a bit too dense for me. :-)

So, firstly, I think we are only concerned here with our section
"5.2.2 Server mapped byte ranges" - correct me if I am wrong.
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped

And in section 5.2.2 the issue you are pointing out is not with any of
the requests, but only with the replies - and only with those replies
that contain a "Content-Range-Mapping" header to explain what the
original request referred to, correct?

Further, you are concerned with the cachability of the replies that
contain a "Content-Range-Mapping" entity-header field, correct?

>From reading "10.2.7 206 Partial Content" in rfc2616, it seems to me
that you are mostly worried about the sentences "the response
SHOULD/MUST NOT include other entity-headers". These sentences both
refer only to the situation where the 206 response was created as a
result to an "If-Range" header in the request.

Now, none of our examples actually uses an "If-Range" header, so from
that POV we are ok. But to be thorough, we should look at what an
exchange with an "If-Range" header would actually look like and what
effect it has on cachability and whether it would need the
"Content-Range-Mapping" entity-header field.

To understand "If-Range" and cachability, I had to read sections
"14.27 If-Range", "13.3.3 Weak and Strong Validators" and "3.11 Entity
Tags".

So when would "If-Range" be used?

A UA would use If-Range, when it already has parts of a resource, but
wants an up-to-date copy of the entire resource. If the resource is
unchanged, it only wants the part(s) that it is missing; otherwise,
the entire new resource.

The actual situation that I read where it would be used is where a
connection gets broken after a certain number of bytes and the UA
wants to go back and get the rest of the request.

So, here is an example exchange with "If-Range":

1. Original exchange:

User → UA (1):
http://www.example.com/video.ogv#10-20

UA (1) → Proxy (2) → Origin Server (3):
GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: t:npt=10-20

Origin Server (3) → Proxy (4) → UA (5):
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Content-Range-Mapping: t:npt 9.85-21.16/0.0-653.79
Etag: "abc"

{binary data}

UA only receives bytes 19147-20000

2. If-Range request:

UA (1) → Proxy (2) → Origin Server (3):
GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: 20000-22880
If-Range: "abc"

Origin Server (3) → Proxy (4) → UA (5):
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, track, id
Content-Length: 2880
Content-Type: video/ogg
Content-Range: bytes 20000-22880/35614993
Etag: "abc"

{binary data}

In this situation, the UA already knows the mapping of the byte ranges
to time, so the server would not re-use the Content-Range-Mapping
header, because we are back to just byte range requests.

So, the question is whether there is a different use case for
If-Range, where we already have a piece of the content and want the
full video, but do not know the remaining byte ranges. I guess what it
means is that if we have downloaded #t=0,20 and we want now want the
full resource, we want to make sure that #t=0,20 is still up-to-date.
In this case, since we have already received #0,20, we already know
the bytes up to which we have received it and we know the duration.
So, again, we can do byte range requests.

I honestly fail to construct a situation where we would use If-Range
with non-byte-ranges, but please try.

Cheers,
Silvia.

Received on Tuesday, 8 June 2010 01:04:43 UTC