Bug: *PRINT-BASE* affects radix of Content-Length header in reply
The radix used to print the value of the Content-Length header in reply is affected by the value set for *PRINT-BASE* in my SLIME REPL. This should not happen; Content-Length should always be in base 10 I believe. Here's a minimal test case: (hunchentoot:define-easy-handler (content-length-test :uri "/content-length-test") () "Foo Bar Baz") When *PRINT-BASE* is 10, $ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: 11 ...snipped... * Connection #0 to host localhost left intact Foo Bar Baz When *PRINT-BASE* is 16, $ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: B ...snipped... * Excess found in a non pipelined read: excess = 11 url = /content-length-test (zero-length body) * Connection #0 to host localhost left intact I am running Hunchentoot 1.2.19 on SBCL 1.1.4 on OS X Mountain Lion. Chaitanya
Can you submit a patch to fix the issue? Thanks, Hans 2013/11/5 Chaitanya Gupta <mail@chaitanyagupta.com>
The radix used to print the value of the Content-Length header in reply is affected by the value set for *PRINT-BASE* in my SLIME REPL. This should not happen; Content-Length should always be in base 10 I believe.
Here's a minimal test case:
(hunchentoot:define-easy-handler (content-length-test :uri "/content-length-test") () "Foo Bar Baz")
When *PRINT-BASE* is 10,
$ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: 11 ...snipped... * Connection #0 to host localhost left intact Foo Bar Baz
When *PRINT-BASE* is 16,
$ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: B ...snipped... * Excess found in a non pipelined read: excess = 11 url = /content-length-test (zero-length body) * Connection #0 to host localhost left intact
I am running Hunchentoot 1.2.19 on SBCL 1.1.4 on OS X Mountain Lion.
Chaitanya
I have submitted a pull request: https://github.com/edicl/hunchentoot/pull/62 On Wed, Nov 6, 2013 at 1:05 AM, Hans Hübner <hans.huebner@gmail.com> wrote:
Can you submit a patch to fix the issue?
Thanks, Hans
2013/11/5 Chaitanya Gupta <mail@chaitanyagupta.com>
The radix used to print the value of the Content-Length header in reply is affected by the value set for *PRINT-BASE* in my SLIME REPL. This should not happen; Content-Length should always be in base 10 I believe.
Here's a minimal test case:
(hunchentoot:define-easy-handler (content-length-test :uri "/content-length-test") () "Foo Bar Baz")
When *PRINT-BASE* is 10,
$ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: 11 ...snipped... * Connection #0 to host localhost left intact Foo Bar Baz
When *PRINT-BASE* is 16,
$ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: B ...snipped... * Excess found in a non pipelined read: excess = 11 url = /content-length-test (zero-length body) * Connection #0 to host localhost left intact
I am running Hunchentoot 1.2.19 on SBCL 1.1.4 on OS X Mountain Lion.
Chaitanya
participants (2)
-
Chaitanya Gupta -
Hans Hübner