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.