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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 6:54 PM > To: [EMAIL PROTECTED] > 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:[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. >>> > > > > > > > > > > > > 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. > >
