[hunchentoot-devel] Problem with POST-PARAMETERS in multipart POSTs after r4438

[Hans Hübner]

The patch looks good, I have committed it to the development version.
We really need more and better test cases, to state the obvious.

Thanks!
Hans

On Thu, Aug 20, 2009 at 23:28, Stephen Compall<s11 at member.fsf.org> wrote:
> As of r4438 (Peter's patch), I believe this wipes out post-parameters of
> multipart/form-data POST requests and causes the relevant requests to
> time out.
>
> Specifically, on a multipart/form-data request, the first call to
> `post-parameters` yields a sensible result, whereas future calls yield
> NIL after timing out.
>
> The solution proper is in the first hunk of the patch below, which
> removes the ability to FORCE maybe-read-post-parameters to reread a
> multipart/form-data request, because it can't do that, having emptied
> the stream of the necessary data.
>
> The second hunk, which incidentally fixes the problem as well (only by
> avoiding the confusing behavior of maybe-read-post-parameters in the
> common case of POSTing a non-empty set of parameters, rather than
> solving it), is a specific followup to r4438, which in combination with
> the first hunk merely prevents post-parameters from recalculating the
> alist from the raw data on every call.
>
> Were the first hunk to be changed to warn in the specific case it
> avoids, the second hunk would also serve to eliminate spurious warnings
> about being unable to reread multipart posts.