tor 2006-10-12 klockan 13:19 +0200 skrev Ruediger Pluem:
> I do not think that this matters all too much, because the backend closes
> the connection *immediately* after sending out the response.
To help this, perhaps there should be a check just before sending the
response as well, and send "Con
Jeff Trawick wrote:
>
> On 10/12/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 10/11/2006 11:09 PM, Jeff Trawick wrote:
> > > On 10/11/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> >
> > >> 2. Although GET is mentioned to be idempotent in RFC 2616 (9.1.2)
> > >> along with some ot
Ruediger Pluem wrote:
>
> I do not think that this matters all too much, because the backend closes
> the connection *immediately* after sending out the response. So the socket
> connection check on proxy side that is executed before reusing a connection
> will detect that this socket has been clo
On 12.10.2006 13:26, Mladen Turk wrote:
> Ruediger Pluem wrote:
>
>>
>> But yes, in theory their remains a race here if the proxy reuses the
>> connection
>> faster then the backend needs time to close the socket after sending
>> the response.
>>
>
> Does the problem exists with the current trunk
On 10/12/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
On 10/11/2006 11:09 PM, Jeff Trawick wrote:
> On 10/11/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>> 3. Sometimes servers (including httpd) include a keep-alive header in
>> their response with the parameter
>>timeout set. This ca
Ruediger Pluem wrote:
But yes, in theory their remains a race here if the proxy reuses the connection
faster then the backend needs time to close the socket after sending the
response.
Does the problem exists with the current trunk as well?
The way how trunk detects the closed backend has ch
On 10/11/2006 11:09 PM, Jeff Trawick wrote:
> On 10/11/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>> 3. Sometimes servers (including httpd) include a keep-alive header in
>> their response with the parameter
>>timeout set. This can give a hint when the backend will close its
>> persist
On 10/12/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
On 10/11/2006 11:09 PM, Jeff Trawick wrote:
> On 10/11/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>> 2. Although GET is mentioned to be idempotent in RFC 2616 (9.1.2)
>> along with some other methods
>>it is not a good idea to regar
On 10/11/2006 11:09 PM, Jeff Trawick wrote:
> On 10/11/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>> 2. Although GET is mentioned to be idempotent in RFC 2616 (9.1.2)
>> along with some other methods
>>it is not a good idea to regard a GET / HEAD with query parameters
>> to be idempotent.
On 10/11/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
There is an issue with the proxy code that if a request is sent over
a persistent backend connection (currently only looking at the http case, not
sure if the same thing can happen for other backends like ajp and fastcgi)
it could happen that
There is an issue with the proxy code that if a request is sent over
a persistent backend connection (currently only looking at the http case, not
sure if the same thing can happen for other backends like ajp and fastcgi)
it could happen that this connection gets closed by the backend for timeout
11 matches
Mail list logo
