[hunchentoot-devel] Two bugs in development head (stable version unaffected)
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.
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@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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
participants (2)
-
Hans Hübner -
Wukix Inc.