Me too: "1. I suspect that the content is requested not by IE, but by the Adobe Acrobat plugin." I was unable to view from the changelog of tomcat releases which could be the cause of this strange behaviour. Michele MAsè
On Tue, Jul 31, 2012 at 11:32 PM, Konstantin Kolinko <knst.koli...@gmail.com > wrote: > 2012/8/1 Jose María Zaragoza <demablo...@gmail.com>: > >> The Content-Length header in the above 206 response is not from Tomcat. > >> > >> Tomcat's DefaultServlet does not calculate the whole size of the parts > >> and does not set content-length, and the file size is much more than > >> fits into the buffer. > >> So it would use Transfer-Encoding: chunked in its response and not > >> the one that you cited. > >> There must be some proxy in the way that buffers the data and sends > >> them as one response instead of chunks. HTTPD? Was there some option > >> in it that disables chunked encoding when interacting with IE? > > > > > > Well, i don't know so much, but that doesn't have to do with chunked > > encoding, but Partial Content support, right ? > > And partial content is requested by client (IE) if Content-length is > > very big ( I guess ... ) > > Maybe, IE requests a PDF file (GET) and if it sees a Content-length > > very big , cuts downloading and re-send a GET request with a range of > > bytes. > > > > Chrome looks to perform something like that behaviour > > > > 1. I suspect that the content is requested not by IE, but by the Adobe > Acrobat plugin. > > The "User-Agent" header says that it was IE6, but it is hard to > imagine why the browser by itself would request that strange bytes > range, asking for the tail of the file first. So there is something > else that uses the browser to perform the request. > > 2. To clarify what I said about chunked encoding: > > Tomcat itself does not know the size of data that it sends. So if the > response is HTTP/1.1, the response will be send using > "Transfer-Encoding: chunked" in blocks of bytes (chunks) each prefixed > with the size of the block, up to the terminating block of size 0. It > is a feature of HTTP/1.1 protocol. > > If something sends "Content-Length: 1319458" response header, it must > calculate the size of data, and it can be only done by caching the > whole of response sent by Tomcat. The response headers will not be > sent before the whole data is cached, so the client will observe a > delay. I think there is a possibility that the client can time-out. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
