Subject: Preliminary agenda for Atlanta

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Oct 2012 14:41:29 +1100

... is at:
  http://www.ietf.org/proceedings/85/agenda/agenda-85-httpbis

Suggestions, etc. welcome.

--
Mark Nottingham   http://www.mnot.net/

---

From: "Fall, Kevin" <[email-masked]>
Date: Tue, 23 Oct 2012 04:11:14 +0000

Would like a chance to briefly bring up the range / partial delivery issue
I mentioned on the list.
[and what's behind 
http://tools.ietf.org/id/draft-kfall-httpbis-server-ranges-00.txt]

regards,
- K

---

From: Larry Masinter <[email-masked]>
Date: Tue, 23 Oct 2012 17:52:04 -0700

Could you put some time on the agenda to talk about HTTP testing?
Conformance, performance, feature coverage, "live" client/server interop test frameworks?

Larry
--
http://larry.masinter.net

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Monday, October 22, 2012 8:41 PM
> To: [email-masked] Group
> Subject: Preliminary agenda for Atlanta
> 
> ... is at:

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Oct 2012 14:32:23 +1100

Kevin,

> http://tools.ietf.org/id/draft-kfall-httpbis-server-ranges-00.txt]

We can spend a bit of time on it in the "related work" item of the session on Monday, yes.

To make the use case a bit more concrete, and make sure I understand it, one example AIUI would be a request for

  Range: bytes=100-

to which you return, say:

  Content-Range: bytes 100-200/1000
  ETag: "1234"

and then to a subseqent, identical request

  Content-Range: bytes 100-400/1000
  ETag: "1234"

Correct?

Cheers,

---

From: "Fall, Kevin" <[email-masked]>
Date: Thu, 25 Oct 2012 13:32:44 +0000

That is one case, but perhaps more interesting/controversial is this one:

  Range: bytes=100-

  Content-Range: bytes 200-300/1000.

A subsequent request might likely then be:

  Range: 100-200, 300-1000

for which the responses might be

  Content-Range: 100-200, 300-1000

or even something like

  Range: 100-1000

(although this later case isn't as desirable due the redundancy).

It would still be straightforward to implement the current rule of not
returning multiple ranges unless multiple ranges were given in the request.
Although I don't know if the intent is to continue with this guidance
given a new HTTP version. [?]

A related issue is which response code to use for such responses.
Although 206 seems most logical given the current set of defined codes (it
is, after all, 'Partial Content'), perhaps it might be more clear if a
different code were used.  I'm neutral on that issue for the moment; the
draft suggests 206.

thx
- K

---

From: Zhong Yu <[email-masked]>
Date: Thu, 25 Oct 2012 10:48:05 -0500

Could your use cases be solved by a new transfer coding?

For example, a "shattered" coding, where entity body is transmitted in
pieces, and the pieces are in undetermined order:

  GET /data HTTP/1.1
  TE: shattered

  HTTP/1.1 200 OK
  Transfer-Encoding: shattered, chunked

  message_body=chunked(
    "500-600:" data[500-600]
    "150-300:" data[150-300]
    ....
    )

Client can specify range filters

  GET /data HTTP/1.1
  Range: bytes=1000-
  TE: shattered

  HTTP/1.1 206 Partial Content
  Content-Range : 1000-N/N
  Transfer-Encoding: shattered, chunked

  message_body=chunked(
    "700-800:" data[1700-1800]
    "200-300:" data[1200-1300]
    ....
    )

Zhong Yu

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 25 Oct 2012 22:55:16 +0000

Hi

------ Original Message ------
From: "Fall, Kevin" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: "[email-masked] Group" <[email-masked]>
Sent: 26/10/2012 2:32:44 a.m.
Subject: Re: draft-kfall-httpbis-server-ranges [was: Preliminary agenda 
for Atlanta]
> Content-Range: bytes 200-300/1000.

I'm struggling to see the point of this.

What real world case would something like this solve?  Presumably the 
client would need to request 100-200 again?  If not, then why even deal 
in bytes and part ranges like this at all?

Regards

Adrien

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 26 Oct 2012 15:13:33 +1300

On 26/10/2012 11:55 a.m., Adrien W. de Croy wrote:
> From: "Fall, Kevin"
> client would need to request 100-200 again?  If not, then why even 
> deal in bytes and part ranges like this at all?
>

Squid would potentially implement this.

* stale-while-revalidate and stale-if-error could use cached but not 
quite matching range entities to respond while the upstream request is 
being processed.

  *  our "collaped forwarding" feature has some issues with late 
arriving requests when the start of the response entity has been 
discarded from buffer already. Currently we are forced to re-fetch. This 
would permit the some Range requests to be served despite missing chunks 
of entity.

Amos

---

From: Albert Lunde <[email-masked]>
Date: Thu, 25 Oct 2012 21:40:19 -0500

> pieces, and the pieces are in undetermined order:

Bear in mind the previous issues with denial of service attacks based on 
too-complex range requests.

There needs to be relatively simple bounds (that a server can enforce) 
on the complexity of what one request can ask for.

---

From: "Fall, Kevin" <[email-masked]>
Date: Fri, 26 Oct 2012 03:06:16 +0000

The real world reason this comes up is described in the draft. [basically,
portions of multimedia segments]
The issue is when the server has some portion of an entity that may be out
of sequence from the start.
(that is, the server may have 200-300 but not 100-200.  The client may ask
later for 100-200 or decide to move on without those parts).

I was hoping to have a few mins at the ATL meeting to describe how/why
this issue comes up.

thx
- K

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Oct 2012 11:57:12 +1100

> I was hoping to have a few mins at the ATL meeting to describe how/why

Yes, you're on the agenda. If you have slides, please send them to me beforehand (ideally, in the next few days).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Oct 2012 12:04:37 +1100

Hi Larry,

We've brought it up a couple of time before, and everyone seems to nod their heads and say "yes, testing is important."

As you can see, we're starting to talk about testing compression algorithms and possibly upgrade schemes; is this what you had in mind? Something else? 

I do plan to talk about the specifics of testing as it relates to each issue we bring up, and I imagine that once we get going, we will be doing some interop work, but until we have a draft that's worth implementing (and separate from SPDY), I'm not sure what else we'd talk about.

If you have a specific proposal, that'd be great to talk about, of course. 

Regards,