[Libwebsockets] return values for callback_function

Andy Green andy at warmcat.com
Fri Nov 20 12:42:04 CET 2015



On 20 November 2015 19:01:55 GMT+08:00, Andy Green <andy at warmcat.com> wrote:
>
>
>On 20 November 2015 18:23:36 GMT+08:00, "Charles Prévot"
><prevot at cervval.com> wrote:
>>2015-11-20 10:15 GMT+01:00 Andy Green <andy at warmcat.com>:
>>
>>>
>>>
>>> On 20 November 2015 16:15:59 GMT+08:00, "Charles Prévot" <
>>> prevot at cervval.com> wrote:
>>> >2015-11-19 18:50 GMT+01:00 Andy Green <andy at warmcat.com>:
>>> >
>>> >>
>>> >>
>>> >> On 20 November 2015 01:29:37 GMT+08:00, "Charles Prévot" <
>>> >> prevot at cervval.com> wrote:
>>> >> >Thanks for your answer.
>>> >> >I have another small problem, in the case of a POST request, is
>>> >there a
>>> >> >way
>>> >> >to figure out the size of the body (other than relying on the
>>> >> >Content-Length header) during the LWS_CALLBACK_HTTP call ?
>>> >>
>>> >> No... that is what Content-Length is for.  That's a http thing
>not
>>an
>>> >lws
>>> >> thing.
>>> >>
>>> >> >Because currently, if the body of the POST request is empty, I
>>have
>>> >no
>>> >> >other callback called (no LWS_CALLBACK_HTTP_BODY_COMPLETION) so
>>the
>>> >> >server
>>> >> >waits for a body that never arrives and the client won't have a
>>> >> >response.
>>> >>
>>> >> Is there a Content-Length: 0 header coming in that case?
>>> >>
>>> >Yes there is, so I can use it to solve my problem. But that means a
>>bad
>>> >browser (or a forged request) could mess with the server behaviour
>>by
>>> >sending an empty POST with no Content-Length header. I can live
>with
>>> >that,
>>> >but that could be a security issue (ie if allocating some memory
>for
>>a
>>> >response that will never be sent, a DoS might occur).
>>>
>>> HTTP requests are covered by a 5s timeout.
>>>
>>> I don't hit this timeout. is it supposed to trigger a callback ?
>with
>>LWS_CALLBACK_CLOSED_HTTP ?
>>Currently if I disable my Content-Length=0 check, I have no other
>>callback
>>and the browser is still waiting, even after 5s...
>
>Hum it seems content-length is 0 and POST is going to confuse it, at
>least looking at the code confused me.  I'll try to make a way to
>reproduce this with nc and see what actually happens.

I pushed a patch fixing it.

http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=0a05792d8da5309f0e8a407da7c201a03e151849

Timeouts cover POST and GET fine, but zero content-length POST is a corner case.  The patch makes it do the BODY_COMPLETION callback and http complete flow.

-Andy

>-Andy
>
>>> In fact if you're sending a big file on a slow link, you have to
>>extend
>>> the timeout each time you send a chunk.
>>>
>>> And nothing stops the attacker anyway on any webserver sending a
>>nonzero
>>> content length and just not fulfilling it.... except the timeout.
>>>
>>> -Andy
>>>
>>> >Thanks for your quick replies.
>>> >
>>> >>
>>> >> -Andy
>>> >>
>>> >> >2015-11-19 17:18 GMT+01:00 Andy Green <andy at warmcat.com>:
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >> On 19 November 2015 21:55:01 GMT+08:00, "Charles Prévot" <
>>> >> >> prevot at cervval.com> wrote:
>>> >> >> >Hello,
>>> >> >> >I have a quick question regarding the return values of
>>callback.
>>> >I
>>> >> >get
>>> >> >> >that
>>> >> >> >return 0 will continue and return -1 will close the
>>connection,
>>> >but
>>> >> >in
>>> >> >> >test-server.c you also use return 1 (when building http
>>headers).
>>> >I
>>> >> >> >failed
>>> >> >> >to find any reference on that, is there a difference with
>>> >returning
>>> >> >-1
>>> >> >> >?
>>> >> >>
>>> >> >> For all the 'normal' callbacks the choice is just 0 = ok and
>>> >nonzero
>>> >> >=
>>> >> >> die.  Originally <0 was die which is why -1 was popular.
>>> >> >>
>>> >> >> >Also, the family of http_header functions are not documented
>>> >either
>>> >> >so
>>> >> >> >I'm
>>> >> >> >not sure of the meaning of a non-zero return from their
>>side...
>>> >> >>
>>> >> >> These were introduced to hide whether the underlying
>connection
>>is
>>> >> >using
>>> >> >> http2 or not.  Http2 deals with headers in a radically
>>different,
>>> >> >> binary-coded way, with multiple different options for header
>>> >encoding
>>> >> >> including huffman tables, and the codebook is dynamically
>>updated
>>> >> >during
>>> >> >> the kept-alive connection lifetime.  In particular you can't
>>just
>>> >> >slide
>>> >> >> from headers to content in one packet with http2 as you could
>>with
>>> >> >http1.x.
>>> >> >>
>>> >> >> Anyway for both http1.x and http2 connections, they will
>return
>>> >> >nonzero in
>>> >> >> the case your requested header couldn't fit in the buffer you
>>gave
>>> >> >it.
>>> >> >>
>>> >> >> -Andy
>>> >> >>
>>> >> >> >Sincerely,
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>>
>>>




More information about the Libwebsockets mailing list