RE: multipart 206 responses in HTTP/2.0

So the current thinking is that the separators, the per-body headers, etc would just get stuffed into DATA frames? 

Section 4.1 in draft-ietf-httpbis-p5-range-24 has the following example:
     HTTP/1.1 206 Partial Content
     Date: Wed, 15 Nov 1995 06:25:24 GMT
     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
     Content-Length: 1741
     Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

     --THIS_STRING_SEPARATES
     Content-Type: application/pdf
     Content-Range: bytes 500-999/8000

     ...the first range...
     --THIS_STRING_SEPARATES
     Content-Type: application/pdf
     Content-Range: bytes 7000-7999/8000

     ...the second range
     --THIS_STRING_SEPARATES--

So the above example would translate into a HEADERS frame (+END_HEADERS) covering the first set of headers (e.g. date, last-modified, content-length, content-type) and then everything thereafter (separators, "Content-Type: application/pdf", content-range, binary data, etc) would be wrapped into a DATA frame?

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Friday, October 4, 2013 4:00 PM
To: Osama Mazahir
Cc: HTTP Working Group
Subject: Re: multipart 206 responses in HTTP/2.0

On 4 October 2013 15:46, Osama Mazahir <OSAMAM@microsoft.com> wrote:
> Have we thought about how we are supposed to send a 206 multipart 
> response in HTTP/2.0?

Multipart MIME is invisible to HTTP, as it always has been.  The entire MIME multipart body will just be payload bytes.  Thus, the MIME headers that are included for each multipart portion will be sent in DATA frames.

A 206 status code isn't special in this regard, I'm not sure what you are getting at there.

Received on Friday, 4 October 2013 23:25:29 UTC