Re: Some general SPDY feedback / questions

ok, now I'm confused.

you and I discussed this in Feb 2007 on this list 
(http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/ thread 
RE: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt])

My understanding is that once a request indicates an entity body, 
either it must be sent, or the connection closed.

If the desire is to keep the connection open (e.g. for NTLM), then the 
only option is either send the entire entity, or send it chunked from 
the beginning, and send a 0 chunk (which is actually as far as the 
receiver is concerned the same as sending the entire body) so the 
client can get on with authenticating.

100 Continue simply advises the client that it's possible (more 
likely?) the entity will be accepted, e.g. it's not a 401 or 407 or 3xx 
etc etc.

I can still envisage a server sending 100 continue then a 403 or 401 
after it scanned the content or something, or if some messaging layer 
sent the 100 and a higher one decided auth was required for that 
request.  I don't know if this is prohibited by the spec.

Adrien


------ Original Message ------
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
To: "Adrien W. de Croy" <adrien@qbik.com>;"Mark Nottingham" 
<mnot@mnot.net>;"James M Snell" <jasnell@gmail.com>
Cc: "Roberto Peon" <grmocg@gmail.com>;"ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
Sent: 8/08/2012 10:20:43 a.m.
Subject: RE: Some general SPDY feedback / questions
>This is not correct. Using the 100 continue model explicitly calls out separating on the header/body boundary. There is absolutely no reason for the client to use chunking. The use of 100 was introduced explicitly to deal with PUT and POST in situation where there is potentially a large RTT and it is exposed in common Web client APIs (one case is the .NET HTTP client APIS).
>
>Henrik
>
>-----Original Message-----
>From: Adrien W. de Croy [mailto:adrien@qbik.com]
>Sent: Tuesday, August 07, 2012 3:08 PM
>To: Henrik Frystyk Nielsen; Mark Nottingham; James M Snell
>Cc: Roberto Peon; ietf-http-wg@w3.org
>Subject: Re: Some general SPDY feedback / questions
>
>
>------ Original Message ------
>From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
>
>>
>>A mechanism like the 100-continue is critical for supporting requests containing entity data that results in authentication needed, redirect, or other "intermediate "responses in an efficient and robust manner. It allows the client to send the headers which the server can then use to determine whether it can accept the data and as a result give a go-ahead to the client. You don't want the client to start sending a lot of body data if it has to redo the request.
>>
>>
>
>we had a discussion about this a couple years back, and it was resolved
>that the only way that 100-continue can provide for the ability to
>retain the client connection is if the client sends chunked request
>bodies, and aborts the transfer of the entity by sending a 0 chunk.
>
>I'm not aware of any client that actually does this.
>
>so AFAICT, 100 continue is unnecessary, and in the end just results in
>extra transmissions for pretty much no visible benefit.
>
>If OTOH it allowed the client to decide not to send the body (e.g. to
>auth instead), it could have been useful.
>
>This came up when I did my original proposal for status updates, in
>relation to multi-legged authentication when dealing with large request
>bodies.
>
>Adrien
>
>
>
>
>
>>
>>
>>
>>You can approximate this behavior with careful use of flow-control credits but it will inherently be much cruder because there is no way to separate cleanly on a header/body boundary. As a result it will likely result in wasted bytes transmitted -- something we want to avoid with HTTP/2.0.
>>
>>Expect on the other hand is in general a failed experiment in my opinion -- you can't retrofit such semantics into an existing protocol.
>>
>>Henrik
>>
>>-----Original Message-----
>>From: Mark Nottingham [mailto:mnot@mnot.net]
>>Sent: Tuesday, August 07, 2012 08:44
>>To: James M Snell
>>Cc: Roberto Peon; ietf-http-wg@w3.org
>>Subject: Re: Some general SPDY feedback / questions
>>
>>
>>On 19/07/2012, at 1:37 AM, James M Snell <jasnell@gmail.com> wrote:
>>
>>
>>
>>>
>>>
>>>
>>>On Jul 18, 2012 2:35 PM, "Roberto Peon" <grmocg@gmail.com> wrote:
>>>
>>>>
>>>>[snip]
>>>>
>>>>>
>>>>>3. How are Informational 1xx Status Codes handled? The current SPDY draft does not appear to support "provisional responses".
>>>>>
>>>
>>>
>>>Thank you for the reference to the thread. After reading through it one thing became obvious: while it would likely not be difficult to provide support for a 100-continue like mechanism within spdy, the protocols current design would essentially require a suboptimal hack in order to retain existing http/1.1 semantics and preserve spdy-to-http1.1 pass through or would require that we design a new similar mechanism, optimized for spdy that changes an aspect of http/1.1 semantics.
>>>
>>>As Mark  has pointed out recently, however, our job here currently is to only define a new transport for http and not to change existing http semantics. So i am at a bit of a loss as to what the charter will let us do in this case.
>>>
>>>Mark... any guidance?
>>>
>>>
>>
>>
>>
>>It's a good question. I know that it has come up often on the SPDY list (sometimes raised by me ;).
>>
>>I'd characterise expect/continue as being on the lighter borders of a grey area; it is used, but it does cause interop problems.  HTTPbis hasn't decided to deprecate it, so it does form part of the semantics of HTTP (unlike, for example, chunk extensions, which we have deprecated).
>>
>>However, that doesn't preclude us from deciding to not support it in HTTP/2, *if* we can get a good consensus around doing so. I'd be inclined to have a somewhat higher bar for doing so, however.
>>
>>I'd be interested to hear comments from others, of course.
>>
>>Cheers,
>>
>>--
>>Mark Nottingham
>>http://www.mnot.net/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Received on Tuesday, 7 August 2012 22:43:01 UTC