I have some issues when I try to reload a page which is served by hunchentoot.
Note that this only happens with Safari. Firefox and Chrome seem to behave correctly.
I first observed an issue with weblocks and afterwards I tried plain hunchentoot. The plain hunchentoot exhibits different behaviour, but also a behaviour which seems wrong.
1. Plain hunchentoot --------------------
I did the following with both SBCL and CCL on MacOSX:
- start Common Lisp - do: (ql:quickload "hunchentoot") - do: (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)) which is copied from the documantation. - Point my browser to http://localhost:4242 - Observation 1: Everything looks fine - do: Reload in browser - Observation 2: The 'made with lisp image' is not visible anymore.
Now it seems an additional reload brings the image back. In fact, reload in the browser toggles the visibility of the image.
The developer console of safari seems to indicate that 1/2 the times the request image never arrives.
2. Weblocks ----------- Now this might be a problem with weblocks or hunchentoot, howver the following happens:
- A reload takes about 2.7 minutes (the original page is loaded almost instantaneous. - For all my static resources (e.g. javascript files etc), the requests take about 25 seconds and return status 304 which is: +http-not-modified+ - I have 11 static resources (it seems to be doing about 2 requests in parallel??)
Has anybody seen something similar?
3. Versions ----------- Hunchentoot: 1.2.11 SBCL: "1.1.3.8-3eed775" CCL: "Version 1.8-r15416M (DarwinX8664)" Safari: Version 6.0.2 (8536.26.17)
Kind regards, Wim Oudshoorn.
Wim,
thank you for the bug report. The problem was a bug in Hunchentoot that caused it to set the Content-Length header of a static file response before the incoming If-modified-since header was dealt with. This apparently caused Safari to try to read the response body, which did never complete.
I have pushed a corrective change to github ( https://github.com/edicl/hunchentoot.git). Can you give it a try and also check whether the problem with Weblocks is solved by the fix as well?
-Hans
On Sun, Mar 3, 2013 at 6:05 PM, Willem Rein Oudshoorn woudshoo@xs4all.nlwrote:
I have some issues when I try to reload a page which is served by hunchentoot.
Note that this only happens with Safari. Firefox and Chrome seem to behave correctly.
I first observed an issue with weblocks and afterwards I tried plain hunchentoot. The plain hunchentoot exhibits different behaviour, but also a behaviour which seems wrong.
- Plain hunchentoot
I did the following with both SBCL and CCL on MacOSX:
- start Common Lisp
- do: (ql:quickload "hunchentoot")
- do: (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port
4242)) which is copied from the documantation.
- Point my browser to http://localhost:4242
- Observation 1: Everything looks fine
- do: Reload in browser
- Observation 2: The 'made with lisp image' is not visible anymore.
Now it seems an additional reload brings the image back. In fact, reload in the browser toggles the visibility of the image.
The developer console of safari seems to indicate that 1/2 the times the request image never arrives.
- Weblocks
Now this might be a problem with weblocks or hunchentoot, howver the following happens:
- A reload takes about 2.7 minutes (the original page is loaded almost instantaneous.
- For all my static resources (e.g. javascript files etc), the requests take about 25 seconds and return status 304 which is: +http-not-modified+
- I have 11 static resources (it seems to be doing about 2 requests in parallel??)
Has anybody seen something similar?
- Versions
Hunchentoot: 1.2.11 SBCL: "1.1.3.8-3eed775" CCL: "Version 1.8-r15416M (DarwinX8664)" Safari: Version 6.0.2 (8536.26.17)
Kind regards, Wim Oudshoorn.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hans Hübner hans.huebner@gmail.com writes:
I have pushed a corrective change to github ( https://github.com/edicl/hunchentoot.git). Can you give it a try and also check whether the problem with Weblocks is solved by the fix as well?
Thank you, it indeed fixes both issues, scenario 1 as well as the weblocks problem.
That was a quick find!
Kind regards, Wim Oudshoorn.
-
Hans Hübner -
Willem Rein Oudshoorn