httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bray <Tim.B...@Sun.COM>
Subject Re: Basic query regarding client-server communication with browser setting HTTP 1.0/1.1
Date Wed, 30 May 2007 13:23:37 GMT

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.
>>
>>
>


Mime
View raw message