headers
Adrien de Croy | 1 Mar 2012 01:07
Favicon

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)


On 1/03/2012 12:21 p.m., Henrik Nordström wrote:
> tor 2012-03-01 klockan 11:57 +1300 skrev Adrien de Croy:
>
>> that depends on proxy design.  If the challenges and responses are going
>> over the same TCP connection it's pretty simple.
> I won't go into this. HTTP is message oriented, not connection oriented.

I'm not 100% convinced.  Esp with auth.  Even disregarding NTLM, any 
time you have a challenge and response, if the response comes to a 
server over a different TCP connection, then I think a lot of 
implementations will break.  Maybe therefore they are poorly designed.

If for instance multiple proxy clients are multiplexed over a pool of 
connections between the proxy and a server, so that subsequent requests 
on a connection to a server can be for any proxy client, then the 
server's job of maintaining association of credentials, or deciding when 
to issue a challenge is made much more difficult than if it assumes the 
connection is for only 1 user.

Maybe if assuming 1 connection = 1 user is broken, it should be 
explicitly warned about in the spec.  The alternative though is either 
the server has to challenge every request, or the auth tokens submitted 
by clients can be used without round-trips, or some other token needs to 
be stored and looked up by the server in global (i.e. 
non-connection-oriented) memory.  Basic fits there, but does Digest?  
NTLM certainly doesn't of course.

>
>> the main area we see the problem is actually not in proxy auth, but when
(Continue reading)

Permalink | Reply | 7 comments |
headers
Adrien de Croy | 1 Mar 2012 01:09
Favicon

http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt


On 1/03/2012 12:53 p.m., Poul-Henning Kamp wrote:
> In message<1330559425.24673.149.camel@...>, Henrik =?ISO-8859-1?Q?Nord
> str=F6m?= writes:
>> ons 2012-02-29 klockan 15:16 -0800 skrev Mike Belshe:
>>
>>> The problem with upgrade is that it costs a round trip of latency.
>> Only if you are pipelining and then only on the second request, and
>> pipelining on the first request is generally a bad idea anyway. So no.
> There is of course an incredible evil way to indicate what protocol
> you want, without expending a RTT:
>
> Have the server send a TCP option in the SYN+ACK packet that tells
> you what it can do on this TCP connection.

Heh..  I was just about to suggest a TCP option.

I don't think stack support is that good for such things though.

>
> /me<- ducks
>

--

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
Permalink | Reply | 1 comment |
headers
Adrien de Croy | 1 Mar 2012 01:13
Favicon

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)


NTLM could be made non-connection-oriented if http auth had some sort of 
context attribute that identified the auth conversation (in both 
challenges and responses), instead of having to associate it with the 
connection.

Adrien

On 1/03/2012 1:07 p.m., Adrien de Croy wrote:
>
>
> On 1/03/2012 12:21 p.m., Henrik Nordström wrote:
>> tor 2012-03-01 klockan 11:57 +1300 skrev Adrien de Croy:
>>
>>> that depends on proxy design.  If the challenges and responses are 
>>> going
>>> over the same TCP connection it's pretty simple.
>> I won't go into this. HTTP is message oriented, not connection oriented.
>
> I'm not 100% convinced.  Esp with auth.  Even disregarding NTLM, any 
> time you have a challenge and response, if the response comes to a 
> server over a different TCP connection, then I think a lot of 
> implementations will break.  Maybe therefore they are poorly designed.
>
> If for instance multiple proxy clients are multiplexed over a pool of 
> connections between the proxy and a server, so that subsequent 
> requests on a connection to a server can be for any proxy client, then 
> the server's job of maintaining association of credentials, or 
> deciding when to issue a challenge is made much more difficult than if 
> it assumes the connection is for only 1 user.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Amos Jeffries | 1 Mar 2012 01:19
Picon
Favicon

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

On 01.03.2012 12:04, Henrik Nordström wrote:
> tor 2012-03-01 klockan 09:14 +1300 skrev Adrien de Croy:
>> > Not sure there even is a demand for protocol level indicated 
>> logoff
>> > where the server at HTTP level tell the client to invalidate the 
>> cached
>> > credentials.
>>
>> Actually I would like to see this.
>>
>> For example product admin back-ends which use http auth. We'd like 
>> to be
>> able to time out a user so someone else coming along (if the first 
>> user
>> didn't close the browser) doesn't gain access to things they 
>> shouldn't.
>
> Yes. Applications need the ability to time out sessions.
>
> Which begs the question, is that auth framework or scheme?
>
> digest auth can already be used in this manner by tracking server
> nonce(s) or opaque, and forcing a 401 stale=false response if the
> session have been timed out on the server side.

Basic auth can do this in a limited way by using a nonce token instead 
of a password. The server rejecting with 401 the old "password" after a 
timeout. Requiring a new random or cyclic one to be sent by the client.

AYJ
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 1 Mar 2012 01:20

http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

On Wed, Feb 29, 2012 at 4:09 PM, Adrien de Croy <adrien@...> wrote:
>
>
> On 1/03/2012 12:53 p.m., Poul-Henning Kamp wrote:
>>
>> In message<1330559425.24673.149.camel@...>, Henrik
>> =?ISO-8859-1?Q?Nord
>> str=F6m?= writes:
>>>
>>> ons 2012-02-29 klockan 15:16 -0800 skrev Mike Belshe:
>>>
>>>> The problem with upgrade is that it costs a round trip of latency.
>>>
>>> Only if you are pipelining and then only on the second request, and
>>> pipelining on the first request is generally a bad idea anyway. So no.
>>
>> There is of course an incredible evil way to indicate what protocol
>> you want, without expending a RTT:
>>
>> Have the server send a TCP option in the SYN+ACK packet that tells
>> you what it can do on this TCP connection.
>
>
> Heh..  I was just about to suggest a TCP option.
>
> I don't think stack support is that good for such things though.

No doubt this is why SPDY uses a TLS extension (NPN).

-Ekr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrik Nordström | 1 Mar 2012 01:28
Gravatar

Re: Idempotent partial updates

ons 2012-02-29 klockan 23:52 +0000 skrev Mike Kelly:
> Upgrading PUT so it is less specific about replacement wouldn't result
> in this breakage. Clients don't make requests to servers arbitrarily,
> they make them according to whatever application they are fulfilling.
> i.e. if an application is operating on the basis that PUT requests to
> its resources are replacements, then HTTP relaxing the semantics of
> PUT to permit partials would not create breakage.

That's besides the point. To be able to extend PUT like this within
HTTP/1.x it needs to be possible to send the extended request form
arbitrarily without causing breakage. A condition that partial PUT may
only be sent if it's known prior to sending the request that the
receiving server is somehow magically capable of accepting this form of
PUT without causing breakage is not acceptable within HTTP/1.x.

For a change in PUT syntax to be acceptable within HTTP/1.1 you MUST be
able to send such PUT requests to any server without any prior knowledge
of the capabilities of that server and know that the server will process
the request with an acceptable outcome. Storing the partial
representation as the sole representation of the resource is not
regarded as an acceptable outcome so this is not acceptable extension of
PUT within HTTP/1.x.

Regards
Henrik
Permalink | Reply | 3 comments |
headers
Martin Thomson | 1 Mar 2012 01:29
Picon

Re: Idempotent partial updates

2012/2/29 Mike Kelly <mikekelly321@...>:
> Upgrading PUT so it is less specific about replacement wouldn't result
> in this breakage.

PUTv2...which is what PATCH does.

> Clients don't make requests to servers arbitrarily,
> they make them according to whatever application they are fulfilling.

That's coupling.  c.f. statements about that being bad.
Permalink | Reply | 0 comments |
headers
Henrik Nordström | 1 Mar 2012 01:31
Gravatar

http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

ons 2012-02-29 klockan 23:53 +0000 skrev Poul-Henning Kamp:
> In message <1330559425.24673.149.camel@...>, Henrik =?ISO-8859-1?Q?Nord
> str=F6m?= writes:
> >ons 2012-02-29 klockan 15:16 -0800 skrev Mike Belshe:
> >
> >> The problem with upgrade is that it costs a round trip of latency.
> >
> >Only if you are pipelining and then only on the second request, and
> >pipelining on the first request is generally a bad idea anyway. So no.
> 
> There is of course an incredible evil way to indicate what protocol
> you want, without expending a RTT:

Which RTT?

> Have the server send a TCP option in the SYN+ACK packet that tells
> you what it can do on this TCP connection.

We can't assume such detail TCP transport. Might be running over SOCKS
or any other intermediary protocol abstracting away any such details.

Regards
Henrik
Permalink | Reply | 2 comments |
headers
Martin Thomson | 1 Mar 2012 01:35
Picon

Re: Idempotent partial updates

2012/2/29 Henrik Nordström <henrik@...>:
> It also desirable that idempotent methods are used for idempotent
> actions,

Actually, a server has to be prepared for the consequences if it
treats idempotent requests in a non-idempotent fashion.  Clients (and
intermediaries) should not bear the responsibility for bad code...

> but using requests defined as non-idempotent for idempotent
> actions do not cause any breakage, only slight loss of efficiency.

Depends on the axis you use for measuring efficiency.  I somewhat like
the resiliency afforded by idempotent operations and prefer to use
POST and PATCH in a way that they are effectively idempotent, within
the context of the application.  So retrying doesn't result in waste
of other types (orphaned state, etc).
Permalink | Reply | 1 comment |
headers
Adrien de Croy | 1 Mar 2012 01:36
Favicon

http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt


On 1/03/2012 1:31 p.m., Henrik Nordström wrote:
> ons 2012-02-29 klockan 23:53 +0000 skrev Poul-Henning Kamp:
>> In message<1330559425.24673.149.camel@...>, Henrik =?ISO-8859-1?Q?Nord
>> str=F6m?= writes:
>>> ons 2012-02-29 klockan 15:16 -0800 skrev Mike Belshe:
>>>
>>>> The problem with upgrade is that it costs a round trip of latency.
>>> Only if you are pipelining and then only on the second request, and
>>> pipelining on the first request is generally a bad idea anyway. So no.
>> There is of course an incredible evil way to indicate what protocol
>> you want, without expending a RTT:
> Which RTT?
>
>> Have the server send a TCP option in the SYN+ACK packet that tells
>> you what it can do on this TCP connection.
> We can't assume such detail TCP transport. Might be running over SOCKS
> or any other intermediary protocol abstracting away any such details.

similar could happen for SPDY with SSL as well, if an intermediary mitms 
the connection, unless they pass on the option negotiation, it's gone.

Adrien

>
> Regards
> Henrik
>
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane