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

[Wukix Inc.]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110828/ba1d5d61/attachment.html>