And I documented my solution here: (it works
around the problem by changing jQuery instead of Pico).

It's a way to make the jQuery ( Ajax by POST work
properly with PicoLisp.

Ironically the target application - a kind of half intelligent feed
reader whose aim is to prioritize content you like rather than trying
to filter out content you don't like - isn't posting by way of Ajax
yet and may never need to do so. GET has sufficed so far and with GET
the problem does not exist.


On Sun, Nov 23, 2008 at 3:26 PM, Alexander Burger <[EMAIL PROTECTED]> wrote:
> Hi Tomas,
> yes, this is a bug. It hangs in (line), as you suspected. We discussed
> this problem some time ago with Henrik in the chat. The server is indeed
> waiting for either an EOL or EOF.
> When the browser uses HTTP/1.1, together with the "Keep-Alive" option,
> it does not send an EOF after a single transaction (if you try with a
> text browser using HTTP/1.0, like 'w3m', it will work). The picoLisp
> server then accepts chunked transfers.
> The problem is that the server does not use the "Content-Length" field
> of the header, but relies on either one-shot transfers for HTTP/1.0 (and
> thus receives EOF), for chunked transfers on HTTP/1.1 (which seem not to
> be used bye browsers for single-line POST data), or at least an EOL
> (which unfortunately also seems not to be sent).
> The solution would probably be not to use 'line' in
>>                   (if (and *MPartLim *MPartEnd)
>>                      (_htMultipart)
>>                      (for L (split (line) '&)
> but to read the "Content-Length" in '_htHead', and then replace (line)
> with
>   (make
>      (for (N *ContLen (gt0 N))
>         (dec 'N (size (link (char)))) ) )
> A bit clumsy. We cannot simply use
>   (make (do *ContLen (link (char))))
> as this would not work for multi-byte characters.
> Cheers,
> - Alex
> --

Reply via email to