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
-
Chaitanya Gupta -
Hans Hübner