[Libwebsockets] libwebsockets HTTP mode lacks LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION

"Andy Green (林安廸)" andy at warmcat.com
Wed Nov 13 01:08:34 CET 2013


On 11/11/13 14:35, the mail apparently from Johan Lindh included:
> These still return a 403 while being semantically equivalent to a / request.
>
> curl --verbose http://localhost:7681/foo/..

I don't know what version of curl you're using, but it works here with 
the test server... with curl (unlike netcat) it fixed the URL before the 
access so it can't return the 403 you mention.

$ curl --verbose http://localhost:7681/foo/..
* Rebuilt URL to: http://localhost:7681/   <-----
* Adding handle: conn: 0x9f6d50
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x9f6d50) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 7681 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 7681 (#0)
 > GET / HTTP/1.1
 > User-Agent: curl/7.33.0
 > Host: localhost:7681
 > Accept: */*
 >
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: libwebsockets
< Content-Type: text/html
< Set-Cookie: test=LWS_1384294507_516683_COOKIE;Max-Age=360000
< Content-Length: 10478
<
<!DOCTYPE html>
<html lang="en">
...


$ curl --version
curl 7.33.0 (x86_64-redhat-linux-gnu) libcurl/7.33.0 NSS/3.15.2 
zlib/1.2.8 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps 
pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL 
libz Metalink


> curl --verbose http://localhost:7681/foo/../
> curl --verbose http://localhost:7681/foo/../.
> curl --verbose http://localhost:7681/foo/.././

Likewise -->

$ curl --verbose http://localhost:7681/foo/../
* Rebuilt URL to: http://localhost:7681/
....

It requires something like netcat as in attack.sh if you want to deliver 
the literal url.  Maybe your curl is older and doesn't rebuild the url?

However I see the point, which is /blah/.. should back up to / and it 
doesn't right now.

This should solve it

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

> Just to check that it wasn't specific to index accesses, which is
> isn't. Also returns a 403.
>
> http://localhost:7681/foo/../test.html

For the test server, any url with a / in it past the first char is 
forbidden since the test server does not understand directories.

Notice this isn't a behaviour of the library but the test server.

> All requests with a '?' in them seem to return a 415 rather than the
> resource or a 404:

Again the test server's approach is find the mime type first from the 
uri filepath suffix, it doesn't recognize a mime type for "?" so bails 
with the 415.  But this is just the test server's approach it's not a 
behaviour or restriction of the library.

Nobody will deploy the test server without adapting it to what they 
want, lws part of the job is provide convenient events and just enough 
apis to let the user code implement websocket or server communication 
part of what it wants nicely.

That's why we need to take care about '?' --->

> curl --verbose http://localhost:7681/?
> curl --verbose http://localhost:7681/.?
> curl --verbose http://localhost:7681/test.html?x=1
>
> Thank you for staying with it. I appreciate it.

Because most existing user server code doesn't understand it and will 
continue to treat the whole uri with the ? as the filepath if it's not 
using whitelisting.

That should be solved here...

http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=1e3f7b8de914eb3fb8d0e1b24ce8453f13736b18

-Andy

> As to my background, I just starting hacking at web stuff a few weeks
> ago and evaluating websocket libraries last week. But I did start
> hacking in general around the mid -80's and developing software for a
> living in the early 90's, so I've picked up a bit of knowledge on the
> way.
>
> /J
>
>
> On Mon, Nov 11, 2013 at 12:33 AM, "Andy Green (林安廸)" <andy at warmcat.com> wrote:
>> On 11/11/13 02:32, the mail apparently from Johan Lindh included:
>>
>>> Fair enough. Your code, your choices.
>>>
>>> Path normalization in HEAD is still broken though. The following
>>> requests should all resolve to the root resource, but instead returns
>>> "400 Bad". Tested "./libwebsockets-test-server --resource_path
>>> ../share/libwebsockets-test-server" using curl. wget and browsers do
>>> path normalization before submitting the request, so those are not
>>> good test clients.
>>>
>>> http://localhost:7681/../
>>> http://localhost:7681/./
>>> http://localhost:7681/foo/..
>>> http://localhost:7681/foo/../
>>> http://localhost:7681/foo/../.
>>
>>
>> You're right... wget is not actually testing it.
>>
>> I had found this out a year or so ago and created ./test-server/attack.sh
>> using netcat, but frankly I had forgotten it inbetweentimes.
>>
>> I added your tests above and some more to attack.sh, added handling for /./
>> and fixed %xx.
>>
>> If you find some more things broken or think of more test cases it'd be
>> great to add them to attack.sh.
>>
>> It's pretty convenient to use since it spawns the test server with -d 31 and
>> parses the logs in time with the netcat attacks.  If you see "survived"
>> coming at the end it means everything did attack.sh's idea of the right
>> thing for each attack.
>>
>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=6f42910987f4e99f9ec3bfd6fd27ff222665b4a8
>>
>> At the moment if the test server doesn't like something it just hangs up
>> rather than returns a http response.  So I also added this
>>
>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=4e7a13314ddeb5db80babb329f648bdc99b0f181
>>
>> which provides consistent http response code delivery and updated attack.sh
>> accordingly.
>>
>>
>> -Andy
>>
>>>
>>> /J
>>>
>>> On Sun, Nov 10, 2013 at 12:32 PM, "Andy Green (林安廸)" <andy at warmcat.com>
>>> wrote:
>>>>
>>>> On 10/11/13 19:00, the mail apparently from Johan Lindh included:
>>>>
>>>>> I agree that adding code that is seldom used is generally a bad idea.
>>>>> KISS principle and all that.
>>>>>
>>>>> That's why I'd recommend you don't do URL parsing in the state
>>>>> machine, but rather just grab the method, raw URL and HTTP version.
>>>>
>>>>
>>>>
>>>> Having a sanitized uri to work with seems like a basic requirement if we
>>>> can
>>>> dispense with whitelist.
>>>>
>>>>
>>>>> That way you get the best of both worlds. Implementations that don't
>>>>> need to worry about URL paths don't need that code, and some
>>>>> implementations may even require the raw unencoded URL for whatever
>>>>> arcane reasons.
>>>>
>>>>
>>>>
>>>> If your user code wants those kind of things it can add php or whatever
>>>> you
>>>> like.  There'll certainly be more things that it wants than belong in
>>>> libwebsockets.
>>>>
>>>> However the actual URI must be used even in very simple lws http server,
>>>> in
>>>> the example code to support images / html / icon.  So it makes sense to
>>>> ensure it is sanitized there.
>>>>
>>>>
>>>>> To sum it up:
>>>>>
>>>>> I think keeping the HTTP method and version in the WSI state is a good
>>>>> thing since that's the only way other code can get them and doesn't
>>>>> add significant code or data size.
>>>>
>>>>
>>>>
>>>> If you want to provide a patch to parse this in the parser state machine
>>>> and
>>>> provide an unsigned with the http version in a new struct
>>>> _lws_http_mode_related member that should be fine.
>>>>
>>>>
>>>>> I think providing the raw URL allows developers more freedom, even if
>>>>> it also allows them to shoot themselves in the foot.
>>>>
>>>>
>>>>
>>>> You're not wrong but it bloats the minimum footprint use-case into
>>>> needing
>>>> two URI buffers per connection.  Translating it as it comes in as the
>>>> code
>>>> does now is cheaper.
>>>>
>>>>
>>>>> I think keeping URL decoding and path normalization in a separate
>>>>> compile unit(s) provides a very useful feature and still allows the
>>>>> linker to strip it out when not used. Percent decoding and path
>>>>> normalization is something you often want to do on other things than
>>>>> the initial request URL, so most applications would require the
>>>>> function anyway.
>>>>
>>>>
>>>>
>>>> If people want that and the host of other related things they should
>>>> provide
>>>> it in their user code, or perhaps make a small lib with it if there's
>>>> enough
>>>> things (possibly that exists already).  When I look at parsing the
>>>> standardized elements like language selection, cookie options, date
>>>> formats
>>>> etc there seems to enough for a small library. None of that belongs in
>>>> lws.
>>>>
>>>>
>>>>> I think normalizing what looks like paths in the query portion is
>>>>> wrong. Assuming anything about the query part at that stage is
>>>>> premature, and the developer must be allowed to make the choices on
>>>>> how to handle them.
>>>>
>>>>
>>>>
>>>> Yes what I said (but you did not reply to) is that just stopping at ? is
>>>> dangerous when the user code using it is in C and simplistic compared to
>>>> normal web server stacks.  That can be solved by splitting the ? part off
>>>> into a separate header buffer (and not sanitizing that).  The simplistic
>>>> code won't even look at it then, but advanced code can have it as it
>>>> came,
>>>> as a unit.
>>>>
>>>>
>>>>> I would simply grab the first request line into a char buffer in the
>>>>> WSI state, put null terminators after the method, URL and HTTP version
>>>>> and then have pointers to the start of those three into that buffer.
>>>>
>>>>
>>>>
>>>> The way libwebsockets works isn't how you would have personally written
>>>> it... that's not a problem, after all you did not personally write it but
>>>> there it is: just enjoy.  You may even just possibly learn something from
>>>> the different approaches.
>>>>
>>>>
>>>> -Andy
>>>>
>>>>> /J
>>>>>
>>>>> On Sun, Nov 10, 2013 at 9:57 AM, "Andy Green (林安廸)" <andy at warmcat.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 10/11/13 16:39, the mail apparently from Johan Lindh included:
>>>>>>
>>>>>>> I take that to mean you've explicity disabled all IPv6 on your
>>>>>>> machines then. It's available and running by default on pretty much
>>>>>>> everything nowadays, desktop and server alike, Windows, OS/X and
>>>>>>> Linux. I'll certainly provide patches once done unless you beat me to
>>>>>>> it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Some have it disabled in sysconfig others in the kernel config.  My ISP
>>>>>> doesn't provide ipv6 routing.
>>>>>>
>>>>>>
>>>>>>> The benchmarks were not very scientific - server and client (ab -
>>>>>>> apachebench) both running on my MacBook Pro which has a dual core i5
>>>>>>> and runs OS/X 10.9. Take them with a large grain of salt. IMO,
>>>>>>> multithreading the server is mostly useful if a request blocks while
>>>>>>> the server generates something, which is not much of an issue serving
>>>>>>> static files in chunks. It's more likely to be the fact that pion
>>>>>>> supports HTTP/1.1 and can thus use Keep-Alive. TCP handshakes add up.
>>>>>>>
>>>>>>> On the subject of parsing.
>>>>>>>
>>>>>>> Your URI decoder look sane, but the path normalization looks wrong
>>>>>>> from what I can tell by looking at the patch. slash-dot-dot should
>>>>>>> back up a path level, not just be discarded, and path normalization
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The code is different because it is a state machine.  It doesn't set
>>>>>> slash_dot_dot until it has already handled the second dot and it only
>>>>>> exists
>>>>>> as a state to hoover up any more dots.
>>>>>>
>>>>>> I tested it with wget and it seems to work.
>>>>>>
>>>>>>
>>>>>>> should stop at the query part (when '?' is seen). Also, make sure that
>>>>>>> you can't use percent encoding to avoid path normalization - I can't
>>>>>>> really tell from the patch if it does or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes the %xx stuff is shaken out first, then always goes through the
>>>>>> same
>>>>>> logic as the unencoded chars: that is why two kinds of state are
>>>>>> tracked
>>>>>> independently.
>>>>>>
>>>>>> If anyone can find a bug obviously I'll be grateful for a fix.
>>>>>>
>>>>>> About ? I don't think it's safe to just do that.  For example with the
>>>>>> test
>>>>>> app "/?/../../../../etc/passwd" will work (in a bad way) unless the
>>>>>> userland
>>>>>> code explicitly checks for ? as a delimiter.
>>>>>>
>>>>>> You seem to be coming from a traditional webserver background where
>>>>>> that
>>>>>> would be a given to split out the args but it isn't for typical lws
>>>>>> users.
>>>>>>
>>>>>> I guess it needs extending to split it into a different "header" when ?
>>>>>> is
>>>>>> seen in the uri.
>>>>>>
>>>>>>
>>>>>>> You should store the request method and allow both GET and HEAD at a
>>>>>>> minimum. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html for
>>>>>>> details. It should preferably also accept OPTIONS, POST, PUT and
>>>>>>> DELETE, even if the default implementation is just to spit back a "405
>>>>>>> Method Not Allowed".
>>>>>>>
>>>>>>> You should also keep the HTTP version parsed in the request, as the
>>>>>>> server needs to discern a HTTP/1.0 request from a HTTP/1.1 request.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bear in mind this is originally intended for use to give a web UI in
>>>>>> headless devices, we don't need to implement all that to be useful.
>>>>>>
>>>>>> lws doesn't support keep-alive for http1.1 as it stands.
>>>>>>
>>>>>> If you want to provide patches for these I'll add them, but we might be
>>>>>> getting into needing a config option to stop the minimum build case
>>>>>> bloating
>>>>>> out with this stuff that's only useful in a completely different
>>>>>> context.
>>>>>>
>>>>>> -Andy
>>>>>>
>>>>>>
>>>>>>> /J
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Nov 10, 2013 at 8:42 AM, "Andy Green (林安廸)" <andy at warmcat.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/11/13 20:52, the mail apparently from Johan Lindh included:
>>>>>>>>
>>>>>>>>> I forgot to ask: Are you planning to implement IPv6 support?
>>>>>>>>>
>>>>>>>>> Currently, libwebsockets will only bind to the IPv4 address and most
>>>>>>>>> operating systems try IPv6 first, meaning at best address lookup is
>>>>>>>>> delayed (sometimes by several hundred ms) and at worst client
>>>>>>>>> connections simply fail.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't have an ipv6 setup here.
>>>>>>>>
>>>>>>>> I guess it's not that hard since it's only to do with socket-level
>>>>>>>> connection establishment / name resolution which is only a few dozen
>>>>>>>> lines
>>>>>>>> of code.
>>>>>>>>
>>>>>>>> If you're interested in sending a patch I'm certainly interested to
>>>>>>>> look
>>>>>>>> at
>>>>>>>> it.
>>>>>>>>
>>>>>>>> -Andy
>>>>>>>>
>>>>>>>>
>>>>>>>>> /J
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Nov 9, 2013 at 11:29 AM, Johan Lindh <johan at linkdata.se>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Good work. Seems to work fine. I'm evaluating websocketpp alongside
>>>>>>>>>> with libwebsockets and pion. While pion is a fully featured HTTP
>>>>>>>>>> server and very fast, unfortunately it has no WebSocket support and
>>>>>>>>>> no
>>>>>>>>>> apparent easy way to add it.
>>>>>>>>>>
>>>>>>>>>> In case you're interested, here's the current benchmarks, from
>>>>>>>>>> slowest
>>>>>>>>>> to fastest, serving a static HTML file over 10 concurrent
>>>>>>>>>> connections.
>>>>>>>>>> It's an apples-to-oranges comparison since pion is HTTP-only and
>>>>>>>>>> multithreaded to boot, but pion is a good benchmark for how fast
>>>>>>>>>> you
>>>>>>>>>> can get serving HTTP with no shortcuts taken (as in, all headers
>>>>>>>>>> fully
>>>>>>>>>> supported and HTTP/1.1).
>>>>>>>>>>
>>>>>>>>>> websocketpp 0.3.0-alpha4:
>>>>>>>>>> Time per request:       0.334 [ms] (mean, across all concurrent
>>>>>>>>>> requests)
>>>>>>>>>> Transfer rate:          5658.60 [Kbytes/sec] received
>>>>>>>>>>
>>>>>>>>>> libwebsockets HEAD revision:
>>>>>>>>>> Time per request:       0.213 [ms] (mean, across all concurrent
>>>>>>>>>> requests)
>>>>>>>>>> Transfer rate:          8508.20 [Kbytes/sec] received
>>>>>>>>>>
>>>>>>>>>> pion 5.0.4:
>>>>>>>>>> Time per request:       0.158 [ms] (mean, across all concurrent
>>>>>>>>>> requests)
>>>>>>>>>> Transfer rate:          11745.94 [Kbytes/sec] received
>>>>>>>>>>
>>>>>>>>>> Considering that libwebsockets is a fraction of pion's size and has
>>>>>>>>>> WebSockets, it's looking very good indeed.
>>>>>>>>>>
>>>>>>>>>> You're missing a URL decoder though, so let me offer my own. It's
>>>>>>>>>> quite fast and also does path normalization so you can ease up on
>>>>>>>>>> the
>>>>>>>>>> hardcore whitelisting in the test server. :-)
>>>>>>>>>>
>>>>>>>>>> /J
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Nov 9, 2013 at 5:08 AM, "Andy Green (林安廸)"
>>>>>>>>>> <andy at warmcat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09/11/13 08:28, the mail apparently from "Andy Green (林安廸)"
>>>>>>>>>>> included:
>>>>>>>>>>>
>>>>>>>>>>>> On 09/11/13 02:40, the mail apparently from Johan Lindh included:
>>>>>>>>>>>>
>>>>>>>>>>>>> Not having access to any client headers except the URI is
>>>>>>>>>>>>> unacceptable
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You don't have to accept it ^^
>>>>>>>>>>>>
>>>>>>>>>>>>> in LWS_CALLBACK_HTTP, and current HEAD in git does not issue
>>>>>>>>>>>>> WS_CALLBACK_FILTER_PROTOCOL_CONNECTION for HTTP connections.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can see it would be useful to do something, but we need to add
>>>>>>>>>>>> an
>>>>>>>>>>>> enum
>>>>>>>>>>>> then, since that one is specifically when a websocket protocol
>>>>>>>>>>>> connection has been made.
>>>>>>>>>>>>
>>>>>>>>>>>>> Additionally, I strongly suggest adding "Accept:" and
>>>>>>>>>>>>> "If-Modified-Since:" to minilex.c - not being able to safely
>>>>>>>>>>>>> gzip
>>>>>>>>>>>>> or
>>>>>>>>>>>>> do basic cache handling cripples performance.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> More headers sounds reasonable.  At the moment its focus as you
>>>>>>>>>>>> might
>>>>>>>>>>>> guess from the name is serving websocket protocol not http.  But
>>>>>>>>>>>> the
>>>>>>>>>>>> http stuff could indeed cope with more things.
>>>>>>>>>>>>
>>>>>>>>>>>> Are there any other headers people are interested in processing
>>>>>>>>>>>> and
>>>>>>>>>>>> having available inside libwebsockets?  They'd be handled for
>>>>>>>>>>>> both
>>>>>>>>>>>> pure
>>>>>>>>>>>> http and if they were present during the upgrade handshake.  It's
>>>>>>>>>>>> easier
>>>>>>>>>>>> to do them all at once since fiddling with minilex isn't simple
>>>>>>>>>>>> (which
>>>>>>>>>>>> is why it got left to me I guess).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I found myself with some free time thismorning.
>>>>>>>>>>>
>>>>>>>>>>> Additional headers supported in minilex + lws
>>>>>>>>>>>
>>>>>>>>>>>             "Accept:",
>>>>>>>>>>>             "If-Modified-Since:",
>>>>>>>>>>>             "Accept-Encoding:",
>>>>>>>>>>>             "Accept-Language:",
>>>>>>>>>>>             "Pragma:",
>>>>>>>>>>>             "Cache-Control:",
>>>>>>>>>>>             "Authorization:",
>>>>>>>>>>>             "Cookie:",
>>>>>>>>>>>             "Content-Type:",
>>>>>>>>>>>             "Date:",
>>>>>>>>>>>             "Range:",
>>>>>>>>>>>             "Referer:"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=cc13c6f187f47fd31a377d05477f90c0fd7f7452
>>>>>>>>>>>
>>>>>>>>>>> introduce LWS_CALLBACK_FILTER_HTTP_CONNECTION
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=19895bcfd4e89f96100ab2dca041e965973f8e2b
>>>>>>>>>>>
>>>>>>>>>>> Fix ability to access headers in HTTP service
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=84fd949e05d011410dba2abe93dfd2fd7dff1589
>>>>>>>>>>>
>>>>>>>>>>> Add example code to test server for Cookies
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=6cd8880f23354ceeba75d641379c8f07407b0570
>>>>>>>>>>>
>>>>>>>>>>> -Andy
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -Andy
>>>>>>>>>>>>
>>>>>>>>>>>>> Patch for lib/handshake.c attached.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Johan
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/lib/handshake.c b/lib/handshake.c
>>>>>>>>>>>> index 3007426..00e3bc1 100644
>>>>>>>>>>>> --- a/lib/handshake.c
>>>>>>>>>>>> +++ b/lib/handshake.c
>>>>>>>>>>>> @@ -135,6 +135,11 @@ libwebsocket_read(struct
>>>>>>>>>>>> libwebsocket_context
>>>>>>>>>>>> *context,
>>>>>>>>>>>>                    uri_ptr = lws_hdr_simple_ptr(wsi,
>>>>>>>>>>>> WSI_TOKEN_GET_URI);
>>>>>>>>>>>>                    uri_len = lws_hdr_total_length(wsi,
>>>>>>>>>>>> WSI_TOKEN_GET_URI);
>>>>>>>>>>>>
>>>>>>>>>>>> +            if (wsi->protocol->callback &&
>>>>>>>>>>>> wsi->protocol->callback(context, wsi,
>>>>>>>>>>>> +                    LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION,
>>>>>>>>>>>> +                    wsi->user_space, uri_ptr, uri_len))
>>>>>>>>>>>> +                    goto bail_nuke_ah;
>>>>>>>>>>>> +
>>>>>>>>>>>>                    /* union transition */
>>>>>>>>>>>>                    memset(&wsi->u, 0, sizeof(wsi->u));
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>




More information about the Libwebsockets mailing list