On 11/27/06, Bernd Eidenschink <[EMAIL PROTECTED]> wrote:
> Turn off range requests by disabling the following test in
> nsd/fastpath.c:FastReturn()
Thanks for this one. I already removed the line in nsd/return.c which helped
me with this problem: Visitors trying to download a PDF (intended to be
opened by Acrobat Reader) with a Firefox browser (and only! with this one)
had problems to do so. Firefox stops after the first request (or after the
response of the server), as it seems.
I reproduced the behaviour on my local machine with a HTML file containing
just a link to a PDF. I'll have to test it with a more pristine environment
this week, but maybe you can see a similar effect?
Snippet (some headers removed):
====Client Request:
GET /TEST/edition.pdf HTTP/1.1
====Server Response:
Accept-Ranges: bytes
Date: on, 27 Nov 2006 13:35:12 GT
Server: NaviServer/4.99.2
Content-Type: application/pdf
Content-Length: 38644641
Connection: close
====Client Request:
GET /TEST/edition.pdf HTTP/1.1
Keep-Alive: 300
Connection: keep-alive
Range: bytes=38643617-38644640,38439841-38643616,65536-38439840
This seems weird. It's a request for 3 consecutive ranges within the
document, expressed out of order...!?
Reverse them and you get this:
65536-38439840
38439841-38643616
38643617-38644640
====Server Response:
HTTP/1.x 206 Partial Content
Last-Modified: Fri, 24 Nov 2006 09:17:57 GT
Content-Range: bytes 65536-38644640/38644641
Content-Length: 38579105
Here you can see that NaviServer has coalesced them into a single
range. The RFC talks about this, although I'm wondering to what extent
the reversed order of the ranges effects this. The ranges are supposed
to be sent back in the order they were requested, as they're otherwise
not identified.
It doesn't make any sense to me why Mozilla would intentionally
request the ranges out of order. If it really needs the bytes in a
specific order, it can rearrange them on the client machine.
Weird.
