[hunchentoot-devel] Two bugs in development head (stable version unaffected)

[Hans Hübner]

Hi Wukix,

I have committed two changes to the Hunchentoot trunk:

http://bknr.net/trac/changeset/4670
http://bknr.net/trac/changeset/4671

These should fix the problems that you have reported, thank you very
much for that!

- Content-Type and Last-Modified headers in responses for static files
are set before if-modified-since-handling is performed.
- Accept-Ranges header is added to static file responses
- Range header is no longer added for non-partial responses
- Ranges in responses are treated inclusively

Thanks again for your bug reports.  Let us know if there are any other issues.

-Hans

On Mon, Aug 29, 2011 at 4:18 AM, Wukix Inc. <engineering at wukix.com> wrote:
> Hello All,
>
> We have become aware of what seems to be two bugs in Hunchentoot svn head
> (stable version is unaffected).
>
> The first one was discovered by, and should be credited to J.P. Larocque.
> The issue is that not only is Content-Range unnecessarily included in HTTP
> responses, but the upper value of the range is off by 1.
>
> For example, look at these response headers:
> < HTTP/1.1 200 OK
> < Content-Length: 14260
> < Content-Range: bytes 0-14260/*
>
> J.P.'s analysis follows:
> ===============
> Content-Range appears in response, but the status code is 200 rather
> than 206 (Partial Content).  That's odd, but not illegal as far as I
> can tell.
>
> But the Content-Length is definitely inconsistent with the
> Content-Range.  HTTP 1.1 byte ranges are inclusive:
>
> The last-byte-pos value gives the byte-offset of the last byte in
> the range; that is, the byte positions specified are inclusive. Byte
> offsets start at zero.
>   -- HTTP 1.1 14.35.1 Byte Ranges
>      http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
>
> So a range of [0,14260] indicates a length of 14261 bytes, but that's
> different from the Content-Length value.
> ===============
>
> The second issue, which was our own discovery, is that the content-type will
> be incorrect when serving a 304 (Not Modified) response.
>
> The content-type issue can be reproduced in Chrome/Chromium with the
> developer tools enabled. Basically, request some page while viewing the
> network tab. When you hit refresh (triggering status 304 instead of first
> visit 200), you will see the content type will be incorrect for images,
> javascript, or any other non-html.
>
> The content-type issue seems to be caused by a change to the order of
> operations within handle-static-file of misc.lisp. The content type needs to
> be set before before calling handle-if-modified-since, which could otherwise
> abort before the proper content type is set.
>
> Both of these issues can be fixed by reverting to an earlier version of
> misc.lisp. As we already mentioned, the stable version of Hunchentoot is not
> affected.
>
> Thanks,
> The Team at Wukix, Inc.
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>