Subject: HTTP 2.0 "Upgrade" flow

From: Ilya Grigorik <[email-masked]>
Date: Sun, 14 Apr 2013 14:12:41 -0700

> 3.2.  Session Header
>
>  After opening a TCP connection and performing either an HTTP/1.1
>  Upgrade or TLS handshake, the client sends the client session header.
>  The server replies with a server session header.

If the client "knows" that the server is HTTP 2.0 capable (DNS, previous
connection, etc), and wants to skip the HTTP 1.1 Upgrade mechanism and send
"naked" HTTP 2.0 frames from the start (without TLS), I presume it should
still send the session header? As worded above, the behavior is undefined.
I'm guessing, the answer is yes..

> http://tools.ietf.org/html/draft-ietf-httpbis-http2-02#section-2.2
>
> A server that supports HTTP/2.0 can accept the upgrade with a 101
> (Switching Protocols) status code.  After the empty line that
> terminates the 101 response, the server can begin sending HTTP/2.0
> frames.  These frames MUST include a response to the request that
> initiated the Upgrade.

How does this work in light of the client/server session headers? Do we
skip the client session header and send the server session header, followed
by response frames? Or does the client have to wait to get the 101, and
then send the client session header before the connection can proceed?

ig

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Apr 2013 00:39:39 +0300

> I'm guessing, the answer is yes..

That's the way I understood it...

And session header in that case tells that HTTP/2.0 is coming, not HTTP/1.x

> then send the client session header before the connection can proceed?

Of course, client has to wait for server session header or it sends
something designed to cause things to break...

-Ilari

---

From: Ilya Grigorik <[email-masked]>
Date: Sun, 14 Apr 2013 15:03:00 -0700

> something designed to cause things to break...

The "of course" part is not obvious. If this is indeed the intent, then we
should state it explicitly. Aka, the expected flow would be:

 >    GET /default.htm HTTP/1.1
 >    Host: server.example.com
 >    Connection: Upgrade
 >    Upgrade: HTTP/2.0

 <    HTTP/1.1 101 Switching Protocols
 <    Connection: Upgrade
 <    Upgrade: HTTP/2.0

 <    [ HTTP/2.0 server session-header
 <    [ HTTP/2.0 response frames

The client session header
(0x464f4f202a20485454502f322e300d0a0d0a4241520d0a0d0a)
is explicitly omitted in this exchange.

Correct?

ig

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 17 Apr 2013 01:10:15 +0000

> And session header in that case tells that HTTP/2.0 is coming, not HTTP/1.x

In this case, the behavior is defined in the draft. Section 3.2 talks about the "prior knowledge" scenario, in which neither an Upgrade nor a TLS handshake occurs:

http://http2.github.io/http2-spec/#rfc.section.3.2
"If starting HTTP/2.0 with prior knowledge, the client session header is sent upon connection establishment."

> something designed to cause things to break...

However, in the Upgrade scenario, I think the draft is not precise. It follows from 3.8.4 that a SETTINGS frame MUST be the first frame sent by either party in a new session. Since the server session header *is* a SETTINGS frame (section 3.2), it follows that the first thing a server sends is its server session header. So strictly speaking, the server session header is not a response to the client session header. It is simply the first thing the server sends on a new session. In the Upgrade case, the server's session header goes out before the client's, so it is not a response. 

3.2 says:
"The server sends the server session header immediately after receiving and validating the client session header."

That is not true if the server is the first one talking on the new session (as in the Upgrade scenario). In this case, the server is the first one, and it sends its 101, empty line, and then a SETTINGS frame (aka as the server session header). In this case, the server does not have the need nor the chance to validate the client session header before sending its own.

I think section 3.2 should be fixed as follows:

OLD:
After opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake, the client sends the client session header. The server replies with a server session header.

NEW:
After opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake, the client sends the client session header.

OLD:
The server sends the server session header immediately after receiving and validating the client session header.

NEW:
The server sends the server session header (its SETTINGS frame) as the first frame in the new session, per section 3.8.4. 

Section 2.2 could use some work as well:

OLD:
Once the server returns the 101 response, both the client and the server send a session header (Section 3.2).

NEW:
Per section 3.8.4, the first of these HTTP/2.0 frames sent by the server is its SETTINGS frame (which also constitutes the server session header). Upon receiving the 101 response, the client sends its session header (Section 3.2).

Thanks,

Gabriel

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Apr 2013 18:13:06 -0700

++

-=R

On Tue, Apr 16, 2013 at 6:10 PM, Gabriel Montenegro <
[email-masked]> wrote:

> In this case, the behavior is defined in the draft. Section 3.2 talks
> about the "prior knowledge" scenario, in which neither an Upgrade nor a TLS
> handshake occurs:
>
> However, in the Upgrade scenario, I think the draft is not precise. It
> follows from 3.8.4 that a SETTINGS frame MUST be the first frame sent by
> either party in a new session. Since the server session header *is* a
> SETTINGS frame (section 3.2), it follows that the first thing a server
> sends is its server session header. So strictly speaking, the server
> session header is not a response to the client session header. It is simply
> the first thing the server sends on a new session. In the Upgrade case, the
> server's session header goes out before the client's, so it is not a
> response.
>
> 3.2 says:
> "The server sends the server session header immediately after receiving
> and validating the client session header."
>
> That is not true if the server is the first one talking on the new session
> (as in the Upgrade scenario). In this case, the server is the first one,
> and it sends its 101, empty line, and then a SETTINGS frame (aka as the
> server session header). In this case, the server does not have the need nor
> the chance to validate the client session header before sending its own.
>
> After opening a TCP connection and performing either an HTTP/1.1 Upgrade
> or TLS handshake, the client sends the client session header. The server
> replies with a server session header.
>
> NEW:
> After opening a TCP connection and performing either an HTTP/1.1 Upgrade
> or TLS handshake, the client sends the client session header.
>
> OLD:
> The server sends the server session header (its SETTINGS frame) as the
> first frame in the new session, per section 3.8.4.
>
> Per section 3.8.4, the first of these HTTP/2.0 frames sent by the server
> is its SETTINGS frame (which also constitutes the server session header).
> Upon receiving the 101 response, the client sends its session header
> (Section 3.2).
>
> Thanks,
>
> Gabriel
>

---

From: Ilya Grigorik <[email-masked]>
Date: Tue, 16 Apr 2013 21:03:57 -0700

Thanks Gabriel. I think the workflow you outlined makes sense, but a few
wording clarifications..

 3.2 says:
>> That is not true if the server is the first one talking on the new
>> session (as in the Upgrade scenario). In this case, the server is the first
>> one, and it sends its 101, empty line, and then a SETTINGS frame (aka as
>> the server session header). In this case, the server does not have the need
>> nor the chance to validate the client session header before sending its own.
>>
>
> +1

>> or TLS handshake, the client sends the client session header.
Is the client side of this even necessary in Upgrade case? Two scenarios:

a) client is only interested in a single request, but over HTTP 2.0
> GET + Upgrade
< 101 + SETTINGS + response frames

There is no reason for client to respond with its own session header here?
It asked for 2.0, it got 2.0, if it got bogus bytes, it can terminate the
connection.

b) let's assume (a) happens, but client now wants to send another request
in same session..

> HEADERS
< response frames

Once again, there is no reason for client to append its session header
here? It asked for 2.0, it got 2.0, and its continuing to speak 2.0?

>  OLD:
>> The server sends the server session header immediately after receiving
>> and validating the client session header.
>>
>> NEW:
>> +1

>> Upon receiving the 101 response, the client sends its session header
As per comments above, not sure we need the second sentence? The client
session header is required for TLS case, and "naked" (clear text, no
Upgrade) case on port 80. I think..

ig

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Apr 2013 21:23:46 -0700

In your case a), it still simplifies the code to always send the same bytes
regardless of how/when the session is established.
The fact that an HTTP/2 response gets through a transparent proxy doesn't
necessarily mean that an HTTP/2 request will. For the reason above, plus
this, and given how cheap the session header is, it makes sense to simply
always send it.

There is a different potential argument here, though, which is: should the
server wait to respond until after it has received the client's session
header (as that stands the best chance of killing the connection when going
through an unhelpful transparent proxy)?
Doing so would make that connection fairly slow (latency wise), however...
-=R

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 17 Apr 2013 05:00:26 +0000

I don't understand why the initial HTTP/1.1 request from the client with 
the Upgrade header wouldn't also contain the client session frame as 
payload.

Or is this because the method may not permit a body?  If so, put it 
encoded into a request header.

Adrien

------ Original Message ------
From: "Ilya Grigorik" <[email-masked]>
To: "Roberto Peon" <[email-masked]>
Cc: "Gabriel Montenegro" <[email-masked]>; "Ilari 
Liusvaara" <[email-masked]>; "[email-masked] Group" 
<[email-masked]>
Sent: 17/04/2013 4:03:57 p.m.
Subject: Re: HTTP 2.0 "Upgrade" flow
>Thanks Gabriel. I think the workflow you outlined makes sense, but a 
>few wording clarifications..
>
>
>>>3.2 says:
>>>"The server sends the server session header immediately after 
>>>receiving and validating the client session header."
>>>
>>>session (as in the Upgrade scenario). In this case, the server is the 
>>>first one, and it sends its 101, empty line, and then a SETTINGS 
>>>frame (aka as the server session header). In this case, the server 
>>>does not have the need nor the chance to validate the client session 
>>>header before sending its own.
>+1
>
>There is no reason for client to respond with its own session header 
>here? It asked for 2.0, it got 2.0, if it got bogus bytes, it can 
>terminate the connection.
>
>b) let's assume (a) happens, but client now wants to send another 
>request in same session..
>
> > HEADERS
>< response frames
>
>>>The server sends the server session header immediately after 
>>>receiving and validating the client session header.
>>>
>>>NEW:
>>>The server sends the server session header (its SETTINGS frame) as 
>>>the first frame in the new session, per section 3.8.4.
>>>
>+1
>
>>>Once the server returns the 101 response, both the client and the 
>>>server send a session header (Section 3.2).
>>>
>>>NEW:
>>>Per section 3.8.4, the first of these HTTP/2.0 frames sent by the 
>>>server is its SETTINGS frame (which also constitutes the server 
>>>session header). Upon receiving the 101 response, the client sends 
>>>its session header (Section 3.2).
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Apr 2013 22:18:54 -0700

As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried in
the headers in the UPGRADE request.
However, this isn't enough by itself-- you still want to cause transparent
proxies to barf when you start speaking HTTP/2 if they're not going to be
able to handle it.
-=R

On Tue, Apr 16, 2013 at 10:00 PM, Adrien W. de Croy <[email-masked]> wrote:

> Liusvaara" <[email-masked]>; "[email-masked] Group" <
> [email-masked]>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Apr 2013 17:54:46 +1200

On 17/04/2013 5:18 p.m., Roberto Peon wrote:
> As proposed by Gabriel, SETTINGS (or equivalent) would/could be 
> carried in the headers in the UPGRADE request.
> However, this isn't enough by itself-- you still want to cause 
> transparent proxies to barf when you start speaking HTTP/2 if they're 
> not going to be able to handle it.

This is why the original proposal by Willy T. listed each of the HTTP/2 
"seeding" headers sent over HTTP/1.1 in the Upgrade request as a 
Connection header alongside Connection:Upgrade. So intermediaries would 
strip them away as well and break the Upgrade attempt cleanly.

Amos

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Apr 2013 23:02:12 -0700

Do we know how effective that is? I've no idea how often transparent
proxies bother about correctness w.r.t. things like this :(
-=R

On Tue, Apr 16, 2013 at 10:54 PM, Amos Jeffries <[email-masked]>wrote:

>> As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried
>> in the headers in the UPGRADE request.
>> transparent proxies to barf when you start speaking HTTP/2 if they're not
>> going to be able to handle it.
>>
>
> "seeding" headers sent over HTTP/1.1 in the Upgrade request as a Connection
> header alongside Connection:Upgrade. So intermediaries would strip them
> away as well and break the Upgrade attempt cleanly.
>
> Amos
>
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 17 Apr 2013 08:27:16 +0200

Hi Roberto,

> proxies to barf when you start speaking HTTP/2 if they're not going to be

However if the client knows from a previous connection that HTTP/2 is
supported as an upgrade along the path, it can safely send its settings
next to the headers, just as some browsers do with CONNECT requests sent to
proxies. If a transparent proxy fails on this, it means it tried to parse
the data following the headers as a new HTTP request, which means it's not
compatible with the Upgrade mechanism anyway.

Willy

---

From: Roberto Peon <[email-masked]>
Date: Tue, 16 Apr 2013 23:34:25 -0700

Yup. The question there is only how we can do a reasonably effective
fast-fail with minimal effort.
-=R

On Tue, Apr 16, 2013 at 11:27 PM, Willy Tarreau <[email-masked]> wrote:

> transparent

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Apr 2013 21:15:37 +1000

Personally, I'm not thrilled with how the server session header is conflated with a SETTINGS frame... if we're going to require that the server send a SETTINGS frame first (which is fine), let's just come out and say that, rather than making it a side effect of requiring a (largely fictional) server session header.

YMMV.

--
Mark Nottingham   http://www.mnot.net/

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 17 Apr 2013 17:02:01 +0000

> Personally, I'm not thrilled with how the server session header is conflated
> with a SETTINGS frame... if we're going to require that the server send a
> SETTINGS frame first (which is fine), let's just come out and say that, rather
> than making it a side effect of requiring a (largely fictional) server session
> header.

The spec already says that in section 3.8.4 that a SETTINGS frame MUST be the first frame sent by either party in a new session.

So that part is fine. If we wish to say that a server has no session header, that would be fine. 

As for " As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried in the headers in the UPGRADE request."

For the record, I did not say that in the Upgrade scenario the client session header is sent in HTTP/1.1 along with the Upgrade request. My understanding is that the Upgrade request goes without the client session header. As we have discussed in Orlando, we could add some HTTP/1.1 headers to address the known state by conveying *some* of the settings (only those absolutely necessary to achieve known initial state). But that's a separate proposal/discussion from this thread.

At any rate, the server sends back the 101, and begins its HTTP/2.0 traffic by  sending its SETTINGS frame and its response frames, and the client upon receiving the 101, and only then, begins sending HTTP/2.0 traffic starting with its client session header (which includes the magic sequence and the client SETTINGS frame).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Apr 2013 14:32:25 -0700

I've made Gabriel's suggested edits and cleaned up the first part of
the session header stuff.  It does help.

https://github.com/http2/http2-spec/commit/d6eefeafc362cd22a639bd608f8601b04820dc7b

Marks comment regarding the fictitious nature of the session header is
fair, but I find it an convenient abstraction from an editorial
perspective.  Again, YMMV.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 17 Apr 2013 21:42:01 +0000

My understanding was that we would not be sacrificing the first request 
due to a requirement to upgrade.

In order for the server to send an actual response, if it needs the 
client session header, this should be sent in the initial request which 
includes the upgrade.

Otherwise we just added a RTT

Adrien

------ Original Message ------
From: "Gabriel Montenegro" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: "Ilari Liusvaara" <[email-masked]>; "Ilya Grigorik" 
<[email-masked]>; "[email-masked] Group" <[email-masked]>
Sent: 18/04/2013 5:02:01 a.m.
Subject: RE: HTTP 2.0 "Upgrade" flow
>The spec already says that in section 3.8.4 that a SETTINGS frame MUST 
>be the first frame sent by either party in a new session.
>
>As for " As proposed by Gabriel, SETTINGS (or equivalent) would/could 
>be carried in the headers in the UPGRADE request."
>
>For the record, I did not say that in the Upgrade scenario the client 
>session header is sent in HTTP/1.1 along with the Upgrade request. My 
>understanding is that the Upgrade request goes without the client 
>session header. As we have discussed in Orlando, we could add some 
>HTTP/1.1 headers to address the known state by conveying *some* of the 
>settings (only those absolutely necessary to achieve known initial 
>state). But that's a separate proposal/discussion from this thread.
>
>At any rate, the server sends back the 101, and begins its HTTP/2.0 
>traffic by sending its SETTINGS frame and its response frames, and the 
>client upon receiving the 101, and only then, begins sending HTTP/2.0 
>traffic starting with its client session header (which includes the 
>magic sequence and the client SETTINGS frame).
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Apr 2013 14:51:47 -0700

It's possible that the client could pipeline the session header, but
that does stand a chance of being subsumed into the initial request.
I expect packet-based hacks.

On 17 April 2013 14:42, Adrien W. de Croy <[email-masked]> wrote:
>
> My understanding was that we would not be sacrificing the first request due
> to a requirement to upgrade.
>
> In order for the server to send an actual response, if it needs the client
> session header, this should be sent in the initial request which includes
> the upgrade.
>
>> The spec already says that in section 3.8.4 that a SETTINGS frame MUST be
>> the first frame sent by either party in a new session.
>>
>> As for " As proposed by Gabriel, SETTINGS (or equivalent) would/could be
>> carried in the headers in the UPGRADE request."
>>
>> understanding is that the Upgrade request goes without the client session
>> header. As we have discussed in Orlando, we could add some HTTP/1.1 headers
>> to address the known state by conveying *some* of the settings (only those
>> absolutely necessary to achieve known initial state). But that's a separate
>> proposal/discussion from this thread.
>>
>> traffic starting with its client session header (which includes the magic
>> sequence and the client SETTINGS frame).
>>
>>
>
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 17 Apr 2013 21:56:23 +0000

I think it would need to go in as a header.  Maybe even as an attribute 
to the Upgrade?  Not sure if that supports such things.  E.g.

GET /bob.txt HTTP/1.1
Host: somewhere.co.nz
Upgrade: HTTP/2.0 ; session=[......]

so that the server can respond with the resource in any case.

Adding a RTT to all HTTP 2.0 connections I thought had been decided was 
a non-starter.  Or compared to TLS setup phase + NPN maybe it's no 
worse.

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Gabriel Montenegro" <[email-masked]>; "Mark 
Nottingham" <[email-masked]>; "Ilari Liusvaara" 
<[email-masked]>; "Ilya Grigorik" <[email-masked]>; 
"[email-masked] Group" <[email-masked]>
Sent: 18/04/2013 9:51:47 a.m.
Subject: Re: HTTP 2.0 "Upgrade" flow
>>client
>>>>   with a SETTINGS frame... if we're going to require that the server 
>>>>send
>>>>  a
>>>>   SETTINGS frame first (which is fine), let's just come out and say 
>>>>that,
>>>>  rather
>>>>   than making it a side effect of requiring a (largely fictional) 
>>>>server
>>>>  session
>>>>   header.
>>>
>>>
>>>session

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Apr 2013 15:00:47 -0700

So you intend to make client SETTINGS available to the server prior to
the server commencing transmission.  This is the essence of what
Gabriel intends with his known state proposal.  He is concerned by the
asymmetry of the exchange when Upgrade is involved (as opposed to the
TLS session startup).  You should talk to Gabriel.

On 17 April 2013 14:56, Adrien W. de Croy <[email-masked]> wrote:
>
> I think it would need to go in as a header.  Maybe even as an attribute to
> the Upgrade?  Not sure if that supports such things.  E.g.
>
> GET /bob.txt HTTP/1.1
> Host: somewhere.co.nz
> Adding a RTT to all HTTP 2.0 connections I thought had been decided was a
> non-starter.  Or compared to TLS setup phase + NPN maybe it's no worse.
>
>
> Adrien
>
>
>>>> be
>>>> be

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 17 Apr 2013 22:07:34 +0000

my main concern is what does a forward proxy do.

the client may choose to maintain a database of known http2 capable 
servers.  This may be too much of a burden for the proxy.

Discovery at the proxy could be a bit of a burden as well.

A proxy offering 2.0 support to 2.0 clients but still having to talk to 
the great unwashed internet has quite a dilemma.  The safe/lazy/whatever 
option for the proxy may be to always use the Upgrade option.  Adding a 
RTT in this case will be seen by clients/customers as a performance 
degradation in many cases.

Or maybe I've not thought this through properly.

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Gabriel Montenegro" <[email-masked]>; "Mark 
Sent: 18/04/2013 10:00:47 a.m.
>>>>>>    Personally, I'm not thrilled with how the server session header 
>>>>>>is
>>>>>>   conflated
>>>>>   So that part is fine. If we wish to say that a server has no 
>>>>>session
>>>>>   header, that would be fine.
>>>>>
>>>>>   header. As we have discussed in Orlando, we could add some 
>>>>>HTTP/1.1
>>>>>  headers
>>>>>   to address the known state by conveying *some* of the settings 
>>>>>(only
>>>>>  those
>>>>>   absolutely necessary to achieve known initial state). But that's 
>>>>>a
>>>>>  separate

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Apr 2013 15:11:06 -0700

I think that you either send the session header immediately after the
first request (the Upgrade) and risk having it swalled, or you send it
immediately before the next (HTTP/2.0) request.  In either case, you
don't incur an RTT delay.

If you thought that the server would wait for the client session
header before sending its SETTINGS, then I don't think that was every
the intention (the recent edits from Gabriel fix that problem, I
hope).  That would add an RTT and we don't want that.

On 17 April 2013 15:07, Adrien W. de Croy <[email-masked]> wrote:
> the client may choose to maintain a database of known http2 capable servers.
> This may be too much of a burden for the proxy.
>
> A proxy offering 2.0 support to 2.0 clients but still having to talk to the
> great unwashed internet has quite a dilemma.  The safe/lazy/whatever option
> for the proxy may be to always use the Upgrade option.  Adding a RTT in this
> case will be seen by clients/customers as a performance degradation in many
> cases.
>
>>> to

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 17 Apr 2013 22:36:54 +0000

Hi

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Gabriel Montenegro" <[email-masked]>; "Mark 
Sent: 18/04/2013 10:11:06 a.m.
>first request (the Upgrade) and risk having it swalled,
that could do nasty things if the server is only 1.1

>or you send it
next request may not exist.

Adrien
>>servers.
>>>>>>    session header, this should be sent in the initial request 
>>>>>>which
>>>>>>   includes
>>>>>>    the upgrade.
>>>>>>
>>>>>>>>     Personally, I'm not thrilled with how the server session 
>>>>>>>>header is
>>>>>>>>    conflated
>>>>>>>    The spec already says that in section 3.8.4 that a SETTINGS 
>>>>>>>frame
>>>>>>>  MUST
>>>>>>>   be
>>>>>>>    session header is sent in HTTP/1.1 along with the Upgrade 
>>>>>>>request.
>>>>>>>  My
>>>>>>>    absolutely necessary to achieve known initial state). But 
>>>>>>>that's a
>>>>>>>   separate
>>>>>>>    traffic by sending its SETTINGS frame and its response frames, 
>>>>>>>and
>>>>>>>  the

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 17 Apr 2013 22:54:31 +0000

> next request may not exist.

So the client is done then. Why is it an issue? What would be gained by the client sending its session header after it was done effectively using the session?

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 17 Apr 2013 23:10:53 +0000

Hi

------ Original Message ------
>So the client is done then. Why is it an issue? What would be gained by 
>the client sending its session header after it was done effectively 
>using the session?

proxy doesn't know if the client is done or not.