Re: Other work items

On 2014-06-14 10:35, Matthew Kerwin wrote:
> On 14 June 2014 17:01, Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>>wrote:
>
>     On 2014-06-13 23:50, Matthew Kerwin wrote:
>
>
>         On 14 June 2014 05:00, Mark Nottingham <mnot@mnot.net
>         <mailto:mnot@mnot.net>
>         <mailto:mnot@mnot.net <mailto:mnot@mnot.net>>> wrote:
>
>              On 12 Jun 2014, at 4:55 pm, Julian Reschke
>         <julian.reschke@gmx.de <mailto:julian.reschke@gmx.de>
>              <mailto:julian.reschke@gmx.de
>         <mailto:julian.reschke@gmx.de>>__> wrote:
>
>               > - addressing the C-E/Range Request issue
>
>              That needs a draft and a serious amount of discussion
>         on-list first;
>              two hours in a room in Toronto are not going to move it
>              significantly forward if we don’t have those first.
>
>              Is anyone writing a draft here?
>
>
>         I'm thinking about it, but I'm not​​ sure what approach to take.
>         I have the start of a h2 extension-based
>         draft here, but that's only the tip of the iceberg.
>
>
>     As this is a HTTP/1.1 problem as well, the right solution IMHO is
>     define a new range unit (bytes-before-content-coding).
>
>
> Not really -- HTTP/1.1 has transfer encoding, which is applied after
> ranges (it also has the advantage(?) of compressing the range metadata,

But it's not used. What's easier: deploying a new range unit, or getting 
TE: gzip deployed?

> eliminating the cost of all those duplicate 'Content-Type' headers). A
> before-content-coding range request doesn't really make sense,

Why not? Do you think it wouldn't work? Please be a bit more concrete.

> especially if you're not applying C-E dynamically (assuming the server
> has an unencoded representation handy, assuming that encoding the range
> is somehow equivalent to encoding the whole, etc.).
>
> I think the C-E/Range request issue is unique to HTTP/2, except that
> nobody seems to have implemented T-E in HTTP/1.1.

See.

>               > - common header field syntax (JSON?)
>
>              This is VERY speculative (although I have thought about it
>         too). I-D?
>
>
>         Or perhaps revisiting draft-snell-httpbis-bohe.
>
>
>     Again, this was about HTTP in general.
>
>
> I see.  In that case, why not XML?  ;)

I'm one of those people left who actually prefer XML to JSON in many 
cases. However I believe this isn't one of these cases.

Best regards, Julian

Received on Saturday, 14 June 2014 09:10:56 UTC