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:[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 1:21 AM
To: [email protected]
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.
