NYCPHP Meetup

[Jonathan Hendler]

Thanks Chris -
I respond inline below:

Chris Shiflett wrote:

>Jonathan Hendler wrote:
>  
>
>>Has anyone been able to get around the issue of the HTTP header
>>Connection: close being ignored by server/client?
>>    
>>
>
>Sending this header is a courtesy. It doesn't dictate whether you can 
>close the connection - it just provides a means to notify the other party.
>  
>
It seems to work in some cases - see below.

>In addition, this header is used to alter the default behavior. In 
>HTTP/1.1, keep-alive is the default behavior. In HTTP/1.0, it's not.
>  
>
I though Connection: close was HTTP/1.1 only, and not HTTP/1.0
I tried adding header("Cache-Control: no-cache");  with no luck also.

>>You would use this if you want to execute a redirect and then
>>continue with a bunch of other code without the client being
>>delayed.
>>    
>>
>
>Remember that you're still just sending an HTTP response. If it has a 
>3xx status code and a Location header, the client will request the new 
>resource, but it can't know about it prior to receiving the original 3xx 
>response.
>  
>
If I understand you, I think that's ok. There is only one 302/Location sent.

>>If you run the code below you will observe a 30 second delay.
>>The desired behaviour is that after the the flush(); the client
>>moves on.
>>    
>>
>
>There are a few things to consider. First, you want to be sure that the 
>use of flush() is forcing a chunked response. Use something like 
>LiveHTTPHeaders to verify this. (If you see a Content-Length header, 
>that's problem number one.)
>  
>
It's chunked, no content-length header.

>If you're issuing a chunked response, you want to make sure that the 
>client receives the response line and all of the HTTP headers before 30 
>seconds have passed. After all, it can't redirect before it is asked to.
>  
>
I used apache ab to verify  with the -v 3 option - the headers are sent 
when I want them to be.
But I do get : "WARNING: Response code not 2xx (302)"
Interestingly wget follows the redirect instantly  - and the rest of the 
code still triggers correctly - so Connection: close isn't ignored by it.
Also, I notice that although I try to force a http/1.0 in apache, if the 
request is 1.1 it send a 1.1 - and also adds a /Content-Type: text/html; 
charset=ISO-8859-1
/after the the Connect: close

>Lastly, you want to be sure that other systems aren't buffering this 
>response and interfering with your plan. If you're using mod_gzip, 
>Apache is likely buffering the response, waiting the full 30 seconds 
>before sending it to the client (compressed). Internet Explorer buffers, 
>so that it doesn't begin to render until it has received a significant 
>portion of the response (making its rendering appear faster, although 
>the overall delivery is actually slower).
>
>  
>
Observed in IIS, Apache, Firefox, IE etc, etc. Granted, there's still 
possibly a gotcha in there.

>It's not required that a client abort a transaction as soon as it knows 
>it must request another resource, but these are the major 
>characteristics you want to check to make that scenario possible.
>  
>
That's the problem - it doesn't seem like there is a way to /require/ 
the abort.