httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Souramita Sen" <Souramita_...@mindtree.com>
Subject RE: Basic query regarding client-server communication with browser setting HTTP 1.0/1.1
Date Wed, 30 May 2007 04:59:08 GMT
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
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message