Re: multipart 206 responses in HTTP/2.0

On 5 Oct 2013, at 00:24, Osama Mazahir <OSAMAM@microsoft.com> wrote:

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

Correct.

> -----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 Saturday, 5 October 2013 16:24:24 UTC