httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: Basic query regarding client-server communication with browser setting HTTP 1.0/1.1
Date Thu, 31 May 2007 08:55:27 GMT
Correct.  But in HTTP/1.0 the connection will close after the response,
and in HTTP/1.1 it may not (if Keepalive is used).

Souramita Sen wrote:
> Thanks everyone for useul information though it's a bit confusing. Okie I
> will put an example and let me know if my udnerstanding is alright.
>
>  
>
> Assuming Web server supporting HTTP 1.1.
>
>  
>
> Suppose text/html page size is 9k and it cant be delivered from server side
> in one go. Suppose the maximun Packet size can be 5k and sender(whoever it
> is: server or client) does not specify content length in the header(According
> to Tim, web client avoids this) . Then,
>
>  
>
> Case 1: Client supports HTTP 1.1 :-
>
>    Server will put the response in two different TCP packets (which are
> basically referred as chunked data.)and send it in one response only.
>
>  
>
> Case 2: Client supports HTTP 1.0 :- 
>
>     Server will put the response in two different HTTP response packets.
>
>  
>
> Is that so?
>
>  
>
>  
>
> -----Original Message-----
> From: Tim.Bray@Sun.COM [mailto:Tim.Bray@Sun.COM] 
> Sent: Wednesday, May 30, 2007 6:54 PM
> To: modules-dev@httpd.apache.org
> Subject: Re: Basic query regarding client-server communication with browser
> setting HTTP 1.0/1.1
>
>  
>
>  
>
> On May 30, 2007, at 4:18 AM, Issac Goldstand wrote:
>
>  
>
>   
>> It will either set it, or rely on the socket close.  When I say socket
>>     
>
>   
>> close, I mean that once the response is complete it closes the  
>>     
>
>   
>> socket -
>>     
>
>   
>> that's the only way the client can know the response is done in  
>>     
>
>   
>> HTTP/1.0
>>     
>
>   
>> if Content-Length isn't set.
>>     
>
>  
>
> Anyone who's written a truly general-purpose Web client,for example a  
>
> large-scale crawler, learns to avoid trust in Content-Length anyhow,  
>
> because, well, it's often wrong.  -Tim
>
>  
>
>  
>
>   
>
>   
>> Souramita Sen wrote:
>>     
>
>   
>>> Issac,
>>>       
>
>   
>
>   
>
>   
>
>   
>>> Thanks for your reply.
>>>       
>
>   
>
>   
>
>   
>
>   
>>> I tried to capture packets through HTTP Analyser while browsing  
>>>       
>
>   
>>> through
>>>       
>
>   
>>> amazon.com and found when browser setting is HTTP 1.0 the server  
>>>       
>
>   
>>> does not
>>>       
>
>   
>>> send a Content-Length in the Response header. I tried sending the  
>>>       
>
>   
>>> screen shot
>>>       
>
>   
>>> of packet captured twice, the mail is getting bounced.
>>>       
>
>   
>
>   
>
>   
>
>   
>>> When you say the server forcibly closes the socket, do you mean it  
>>>       
>
>   
>>> closes
>>>       
>
>   
>>> before sending whole html page. And then the client again connects  
>>>       
>
>   
>>> to the
>>>       
>
>   
>>> server again and again to get rest of the bytes of text/html page.
>>>       
>
>   
>
>   
>
>   
>
>   
>>> Souramita.
>>>       
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>> -----Original Message-----
>>>       
>
>   
>>> From: Issac Goldstand [mailto:margol@beamartyr.net]
>>>       
>
>   
>>> Sent: Wednesday, May 30, 2007 1:21 AM
>>>       
>
>   
>>> To: modules-dev@httpd.apache.org
>>>       
>
>   
>>> Subject: Re: Basic query regarding client-server communication  
>>>       
>
>   
>>> with browser
>>>       
>
>   
>>> setting HTTP 1.0/1.1
>>>       
>
>   
>
>   
>
>   
>
>   
>>> With HTTP/1.0, the server will send a Content-Length: header  
>>>       
>
>   
>>> stating the
>>>       
>
>   
>
>   
>>> length of the response payload and forcibly close the socket when  
>>>       
>
>   
>>> it's
>>>       
>
>   
>
>   
>>> done.  The idea of using the CHUNKED transfer-encoding in HTTP/1.1  
>>>       
>
>   
>>> is to
>>>       
>
>   
>
>   
>>> better allow for the client to know when the response is finished  
>>>       
>
>   
>>> so it
>>>       
>
>   
>
>   
>>> can send a new request on the open socket, without the requirement of
>>>       
>
>   
>
>   
>>> the Content-Length header.
>>>       
>
>   
>
>   
>
>   
>
>   
>>> Does this answer your question?
>>>       
>
>   
>
>   
>
>   
>
>   
>>>   Issac.
>>>       
>
>   
>
>   
>
>   
>
>   
>>> Souramita Sen wrote:
>>>       
>
>   
>
>   
>
>   
>>>> Hi,
>>>>         
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>>> This is common across all web servers I suppose.
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> When a user types an URL in the browser(suppose http:// 
>>>>         
>
>   
>>>> www.abc.com) the
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> server gets request for various MIME types(e.g text/html, text/ 
>>>>         
>
>   
>>>> image etc).
>>>>         
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>>> In HTTP 1.0 each request will initiate separate TCP/IP connection  
>>>>         
>
>   
>>>> and in
>>>>         
>
>   
>
>   
>>> HTTP
>>>       
>
>   
>
>   
>
>   
>>>> 1.1 persistent connection will let the browser send multiple  
>>>>         
>
>   
>>>> requets in one
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> TCP/IP connection itself, and it provides Pipelining too.
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> HTTP 1.1 also provides Transfer-encoding=CHUNKED that allows  
>>>>         
>
>   
>>>> server to send
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> huge text/html files as series of chunks.
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> Till this point, I have understood.
>>>>         
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>>> Now I would like to know how the server sends huge html files  
>>>>         
>
>   
>>>> when browser
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> supports only HTTP 1.0?
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> Because there is no concept of CHUNKED transfer-encoding here,  
>>>>         
>
>   
>>>> how the
>>>>         
>
>   
>
>   
>>> server
>>>       
>
>   
>
>   
>
>   
>>>> handles the response consisting of huge files? If this is not the  
>>>>         
>
>   
>>>> right
>>>>         
>
>   
>
>   
>>> place
>>>       
>
>   
>
>   
>
>   
>>>> for this question to be discussed, please give me a useful URL.  
>>>>         
>
>   
>>>> Actually I
>>>>         
>
>   
>
>   
>>> am
>>>       
>
>   
>
>   
>
>   
>>>> not getting clear from net, not from RFC too.
>>>>         
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>>> Thanks in advance.
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> Souramita.
>>>>         
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>>> DISCLAIMER:
>>>>         
>
>   
>
>   
>
>   
>
>   
>>>> This message (including attachment if any) is confidential and  
>>>>         
>
>   
>>>> may be
>>>>         
>
>   
>
>   
>>> privileged. Before opening attachments please check them for  
>>>       
>
>   
>>> viruses and
>>>       
>
>   
>>> defects. MindTree Consulting Limited (MindTree) will not be  
>>>       
>
>   
>>> responsible for
>>>       
>
>   
>>> any viruses or defects or any forwarded attachments emanating  
>>>       
>
>   
>>> either from
>>>       
>
>   
>>> within MindTree or outside. If you have received this message by  
>>>       
>
>   
>>> mistake
>>>       
>
>   
>>> please notify the sender by return  e-mail and delete this message  
>>>       
>
>   
>>> from your
>>>       
>
>   
>>> system. Any unauthorized use or dissemination of this message in  
>>>       
>
>   
>>> whole or in
>>>       
>
>   
>>> part is strictly prohibited.  Please note that e-mails are  
>>>       
>
>   
>>> susceptible to
>>>       
>
>   
>>> change and MindTree shall not be liable for any improper, untimely or
>>>       
>
>   
>>> incomplete transmission.
>>>       
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>>> DISCLAIMER:
>>>       
>
>   
>>> This message (including attachment if any) is confidential and may  
>>>       
>
>   
>>> be privileged. Before opening attachments please check them for  
>>>       
>
>   
>>> viruses and defects. MindTree Consulting Limited (MindTree) will  
>>>       
>
>   
>>> not be responsible for any viruses or defects or any forwarded  
>>>       
>
>   
>>> attachments emanating either from within MindTree or outside. If  
>>>       
>
>   
>>> you have received this message by mistake please notify the sender  
>>>       
>
>   
>>> by return  e-mail and delete this message from your system. Any  
>>>       
>
>   
>>> unauthorized use or dissemination of this message in whole or in  
>>>       
>
>   
>>> part is strictly prohibited.  Please note that e-mails are  
>>>       
>
>   
>>> susceptible to change and MindTree shall not be liable for any  
>>>       
>
>   
>>> improper, untimely or incomplete transmission.
>>>       
>
>   
>
>   
>
>   
>
>  
>
>
>
> DISCLAIMER:
> This message (including attachment if any) is confidential and may be privileged. Before
opening attachments please check them for viruses and defects. MindTree Consulting Limited
(MindTree) will not be responsible for any viruses or defects or any forwarded attachments
emanating either from within MindTree or outside. If you have received this message by mistake
please notify the sender by return  e-mail and delete this message from your system. Any unauthorized
use or dissemination of this message in whole or in part is strictly prohibited.  Please note
that e-mails are susceptible to change and MindTree shall not be liable for any improper,
untimely or incomplete transmission.
>
>   


Mime
View raw message