[Kepler-Project] xavante/wsapi isn't returning all the POST data

[Yuri Takhteyev]

Two people have reported problems with posts hanging in Sputnik. I
have seen this problem myself once but have not been able to reproduce
it. Now, it looks like Sam has some more additional information. I am
moving this thread to the kepler list, since this seems to be a WSAPI
issue.

Fabio, do you have any input on this? Any chance this could be fixed
for the upcoming Kepler release?

  - yuri

On Sun, Feb 1, 2009 at 2:58 PM, Sam Roberts <vieuxtech at ...> wrote:
> When I run xavante sputnik.ws (following the directions at
> http://spu.tnik.org/en/Installation) and attempt to edit and save a
> wiki page, I get a stack trace.
>
> I believe that wsapi is not correctly read-looping on the tcp stream -
> it appears to only read the POST data from the first two TCP segments.
> That this happens for me, and not some others is consistent with it
> being TCP timing related. I'm a long way away from the server, if you
> are closer all the segments might arrive closer together.
>
> Also, the parser is fragile, in fields(), if read_field_contents()
> doesn't find a mime multipart delimiter, state.pos will be nil, and
> read_field_header's string.sub() will get a pos of nil, and error.
>
>
> Anyhow, the problem starts higher up, though, in wsapi's request.lua
> (I added the assert):
>
> local function parse_post_data(wsapi_env, tab)
> ...
>  elseif string.find(input_type, "multipart/form-data", 1, true) then
>    local length = tonumber(wsapi_env.CONTENT_LENGTH) or 0
>    if length > 0 then
>       local input = wsapi_env.input:read(length) or ""
> assert(#input == length, string.format("attempted to read
> content-length %d, got %d", length, #input))
>       parse_multipart_data(input, input_type, tab)
>    end
>  else
> ...
>
> The mime Content-Length is 3709, but request.lua seems to consistently
> only read 2261 bytes from the wsapi_env.input.
>
> I wiresharked the connection, and Safari is sending a correctly formed
> POST request, with all 3709 bytes of the data.
>
> However, the data arrives in 4 TCP segments, and the first two
> segments are 813 + 1448 = 2261 bytes.
>
> That's exactly how many bytes input:read() is returning. Could be a
> coincidence, but anyhow, its erroring because its not getting all the
> POST data.
>
> Cheers,
> Sam

-- 
http://spu.tnik.org/