From mail at chaitanyagupta.com  Wed Nov  6 08:17:56 2013
From: mail at chaitanyagupta.com (Chaitanya Gupta)
Date: Wed, 6 Nov 2013 13:47:56 +0530
Subject: Bug: *PRINT-BASE* affects radix of Content-Length header in reply
In-Reply-To: <CABj0bwJ_YmQ66QyvLUJeRP0Ge3Jm3Hj360khPcCmA404e1-W0A@mail.gmail.com>
References: <CANOhSrwhqMPXc59xrKA5_Uxd86-FS_a6RdRTscvt80tjCAXBaQ@mail.gmail.com>
	<CABj0bwJ_YmQ66QyvLUJeRP0Ge3Jm3Hj360khPcCmA404e1-W0A@mail.gmail.com>
Message-ID: <CANOhSry+Mei_Zpn4hiaxmWGXqVA=8LcM0sP1OREd7xQ1eYUkKQ@mail.gmail.com>

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 at gmail.com> wrote:
> Can you submit a patch to fix the issue?
>
> Thanks,
> Hans
>
>
> 2013/11/5 Chaitanya Gupta <mail at 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
>>
>


From hans.huebner at gmail.com  Tue Nov  5 19:35:01 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 5 Nov 2013 20:35:01 +0100
Subject: Bug: *PRINT-BASE* affects radix of Content-Length header in reply
In-Reply-To: <CANOhSrwhqMPXc59xrKA5_Uxd86-FS_a6RdRTscvt80tjCAXBaQ@mail.gmail.com>
References: <CANOhSrwhqMPXc59xrKA5_Uxd86-FS_a6RdRTscvt80tjCAXBaQ@mail.gmail.com>
Message-ID: <CABj0bwJ_YmQ66QyvLUJeRP0Ge3Jm3Hj360khPcCmA404e1-W0A@mail.gmail.com>

Can you submit a patch to fix the issue?

Thanks,
Hans


2013/11/5 Chaitanya Gupta <mail at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20131105/336e6ab4/attachment.html>

From mail at chaitanyagupta.com  Tue Nov  5 19:25:32 2013
From: mail at chaitanyagupta.com (Chaitanya Gupta)
Date: Wed, 6 Nov 2013 00:55:32 +0530
Subject: Bug: *PRINT-BASE* affects radix of Content-Length header in reply
Message-ID: <CANOhSrwhqMPXc59xrKA5_Uxd86-FS_a6RdRTscvt80tjCAXBaQ@mail.gmail.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


From james.anderson at setf.de  Sat Nov 16 17:16:44 2013
From: james.anderson at setf.de (james anderson)
Date: Sat, 16 Nov 2013 18:16:44 +0100
Subject: have there been any advances in authentication, content negotiation, or structured response status generation?
Message-ID: <B816C4A6-A021-47BF-9EB9-725A958D6066@setf.de>

good evening;

neither a read through the pages on lists.common-lisp.net, nor a search through gmane's offering yielded anything substantive on facilities to be combined with hunchentoot for

- authentication : alternatively basic, token, and session based?
- content negotiation : resolving request headers against declared availability to yield effective content type, encoding, etc?
- structured response status generation : condition handler -> response status control structures?

when these operations cannot be delegated to a mediating server, is the common practice to code them form scratch?

best regards, from berlin,



From martynov.alexey at gmail.com  Sun Nov 17 08:01:16 2013
From: martynov.alexey at gmail.com (Alexey Martynov)
Date: Sun, 17 Nov 2013 12:01:16 +0400
Subject: have there been any advances in authentication, content negotiation, or structured response status generation?
In-Reply-To: <B816C4A6-A021-47BF-9EB9-725A958D6066@setf.de>
References: <B816C4A6-A021-47BF-9EB9-725A958D6066@setf.de>
Message-ID: <9CFAD005-835D-45C2-A464-131C0AF0D948@gmail.com>

Hi


> 16 ????. 2013 ?., ? 21:16, james anderson <james.anderson at setf.de> ???????(?):
> 
> - content negotiation : resolving request headers against declared availability to yield effective content type, encoding, etc?
> - structured response status generation : condition handler -> response status control structures?
> 
These 2 tasks partially covered by my library at https://github.com/alexey-martynov/cl-avm-http-helpers
I'm trying to make a reusable facility for them and now they solve my needs. It shouldn't be hard to extended them to cover additional cases.

Alexey Martynov

From rm at seid-online.de  Sat Nov 16 21:45:42 2013
From: rm at seid-online.de (Ralf Mattes)
Date: Sat, 16 Nov 2013 22:45:42 +0100
Subject: have there been any advances in authentication, content
 negotiation, or structured response status generation?
In-Reply-To: <B816C4A6-A021-47BF-9EB9-725A958D6066@setf.de>
References: <B816C4A6-A021-47BF-9EB9-725A958D6066@setf.de>
Message-ID: <20131116214542.GA4005@seid-online.de>

On Sat, Nov 16, 2013 at 06:16:44PM +0100, james anderson wrote:
> good evening;

Hi James,

> neither a read through the pages on lists.common-lisp.net, nor a search through gmane's offering yielded
> anything substantive on facilities to be combined with hunchentoot for
> 
> - authentication : alternatively basic, token, and session based?
> - content negotiation : resolving request headers against declared availability to yield effective content type, encoding, etc?
> - structured response status generation : condition handler -> response status control structures?
> 
> when these operations cannot be delegated to a mediating server, is the common practice to code them form scratch?

You probably looked at the wrong floor ;-)
Theses days, those tasks aren't part of the server itself but are handled by some web framework
sitting on top of the server (some even run on multiple server implementations).
So, maybe you need to look at Clack/Caveman/Weblocks et al. (note: I haven't used these for
my projects, but I think I recall reading about sessions in Clacks documentation).

> best regards, from berlin,

Cheers from Freiburg,

  RalfD
 
>