From engineering at wukix.com  Mon Aug 29 02:18:45 2011
From: engineering at wukix.com (Wukix Inc.)
Date: Sun, 28 Aug 2011 19:18:45 -0700
Subject: [hunchentoot-devel] Two bugs in development head (stable version
	unaffected)
Message-ID: <CAL_wdx2apKsfXjnJrqdbF+Rp_C53RCs6rw2gOrv=wYOB+s6DYw@mail.gmail.com>

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>

From hans.huebner at gmail.com  Mon Aug 29 07:17:45 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 29 Aug 2011 09:17:45 +0200
Subject: [hunchentoot-devel] Two bugs in development head (stable
	version unaffected)
In-Reply-To: <CAL_wdx2apKsfXjnJrqdbF+Rp_C53RCs6rw2gOrv=wYOB+s6DYw@mail.gmail.com>
References: <CAL_wdx2apKsfXjnJrqdbF+Rp_C53RCs6rw2gOrv=wYOB+s6DYw@mail.gmail.com>
Message-ID: <CABj0bwJC4tW2Kn3+a66NSdcnQ5PgTUnrGrkBRk4T58OzVSC-Kg@mail.gmail.com>

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
>



From hans.huebner at gmail.com  Tue Aug 30 09:09:36 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 30 Aug 2011 11:09:36 +0200
Subject: [hunchentoot-devel] Hunchentoot development is moving to github
Message-ID: <CABj0bw+9yy-o=4edL7xSGQ=8Lr_juiSuAOqOec73eE1KggWCNw@mail.gmail.com>

Hi,

effective immediately, Hunchentoot development is going on in github:
https://github.com/edicl/hunchentoot - The BKNR subversion repository
will be closed in a while, and github will be the authoritative source
for development versions.

Feel free to fork, send pull requests, open issues and discuss commits.

The "edicl" organization on github also has repository for several
other libraries that Edi has written.  No current development plans
exist, but if you have enhancements to any of these libraries, pull
requests are welcome.

-Hans



From sky at viridian-project.de  Tue Aug 30 09:29:48 2011
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Tue, 30 Aug 2011 11:29:48 +0200
Subject: [hunchentoot-devel] Hunchentoot development is moving to github
In-Reply-To: <CABj0bw+9yy-o=4edL7xSGQ=8Lr_juiSuAOqOec73eE1KggWCNw@mail.gmail.com>
References: <CABj0bw+9yy-o=4edL7xSGQ=8Lr_juiSuAOqOec73eE1KggWCNw@mail.gmail.com>
Message-ID: <20110830092948.GA27230@viridian-project.de>

On Tue, Aug 30, 2011 at 11:09:36AM +0200, Hans H?bner wrote:
> Hi,
> 
> effective immediately, Hunchentoot development is going on in github:
> https://github.com/edicl/hunchentoot - The BKNR subversion repository
> will be closed in a while, and github will be the authoritative source
> for development versions.
> 
> Feel free to fork, send pull requests, open issues and discuss commits.

Great news! :)

  Leslie