[Libwebsockets] Callbacks missing after 3.1 upgrade

Andy Green andy at warmcat.com
Tue Jan 29 03:29:37 CET 2019



On 28/01/2019 12:53, Marcus Engels wrote:
> Hello,
> 
> I have some problems with clients sending post requests to the webserver 
> based on libwebsockets after I linked the server software to the 3.1 
> libwebsockets library (it still works with 3.0.1). To handle POST 
> requests the server should wait for the LWS_CALLBACK_HTTP_BODY callback, 
> parse the request body and reply with some dynamically generated contents.
> 
> It looks as if the LWS_CALLBACK_HTTP_WRITEABLE callback will not get 
> started any more with the newer library. I've added calls to 
> lws_callback_on_writeable to LWS_CALLBACK_HTTP and 
> LWS_CALLBACK_HTTP_BODY but still don't see any calls of 
> LWS_CALLBACK_HTTP_WRITEABLE.  I looked at the 
> minimal-server-form-post-file example but it redirects the client to 
> another page and only mentions that it's possible to respond with a 
> dynamic page.
> 
> I've modified the minimal-http-server-example.c file to print callbacks 

Thanks, I appreciate referencing the mystery to a minimal example so I 
actually have the code.

> on the terminal to test the issue in a reduced environment. The POST 
> request will be send by a small javascript file (+html loader for mount 
> directory). When I link this example to the 3.0.1 libwebsockets library 
> the output for callbacks started looks like the following list:
> 
> LWS_CALLBACK_HTTP
> LWS_CALLBACK_HTTP_BODY  13
> LWS_CALLBACK_HTTP_BODY_COMPLETION  14
> LWS_CALLBACK_HTTP_WRITEABLE
> LWS_CALLBACK_HTTP_WRITEABLE
> LWS_CALLBACK_HTTP_WRITEABLE
> ...
> 
> However when I link the same source code to the 3.1 library file I don't 
> see LWS_CALLBACK_HTTP_WRITEABLE calls any more
> 
> LWS_CALLBACK_HTTP
> LWS_CALLBACK_HTTP_BODY  13
> LWS_CALLBACK_HTTP_BODY_COMPLETION  14
> 
> and the client will only get an empty response to the request (checked 
> target.response in debugger).
> 
> My question is if I missed any required changes in the source code 
> between release 3.0.1 and 3.1. I couldn't find any related info on the 
> internet. Any help would be appreciated.
> 
> I've attached the c source and javascript file that I used for the 
> testing. sendpost_js needs to be renamed to sendpost.js. Looks like 
> attachments with .js extension are not allowed.

I can reproduce what you're seeing, at more verbose logging (-d 1039) 
the immediate reason is clear... the transaction is completed at the 
last piece of the incoming POST body and we're closed, all within 100us. 
  So there is no connection left by the next time around the event loop 
when we might have done the WRITABLE callbacks.

...
[2019/01/29 10:13:19:3098] INFO: lws_handshake_server: 0x1f3a040: No upgrade
[2019/01/29 10:13:19:3098] INFO: Method: 'POST' (1), request for '/dyn/aaaa'
LWS_CALLBACK_HTTP
[2019/01/29 10:13:19:3099] INFO: lws_issue_raw: ssl_capable_write (63) 
says 63
[2019/01/29 10:13:19:3099] INFO: lws_http_action: 0x1f3a040: LRS_BODY 
state set (0x20000016)
LWS_CALLBACK_HTTP_BODY  13
[2019/01/29 10:13:19:3099] INFO: HTTP_BODY_COMPLETION: 0x1f3a040 (http)
LWS_CALLBACK_HTTP_BODY_COMPLETION  14
[2019/01/29 10:13:19:3099] INFO: lws_http_transaction_completed: wsi 
0x1f3a040
[2019/01/29 10:13:19:3099] INFO: lws_http_transaction_completed: 
0x1f3a040: close connection
[2019/01/29 10:13:19:3099] INFO: __lws_close_free_wsi: 0x1f3a040: 
caller: lws_read_h1 bail
...

The difference is coming because your test code handles BODY_COMPLETION, 
but then does a break, exiting the callback via calling thru to the 
dummy callback.

The dummy callback tries to "do something reasonable" for various things 
like BODY_COMPLETION, cgi in and out routing, proxying etc.  Its default 
plan for handling BODY_COMPLETION is to just hang up, on the basis you 
didn't have a better plan or it would have been handled without getting 
there...

	case LWS_CALLBACK_HTTP_BODY_COMPLETION:
	case LWS_CALLBACK_HTTP_FILE_COMPLETION:
		if (lws_http_transaction_completed(wsi))
			return -1;
		break;

You clearly have a specific plan for handling it, since you are asking 
for a WRITABLE callback in your handler.  So just return 0 out of the 
callback after asking for the WRITABLE and don't fall thru to the dummy 
handler for that callback reason.

Just doing that gets you this

LWS_CALLBACK_HTTP
[2019/01/29 10:22:44:4599] INFO: lws_issue_raw: ssl_capable_write (63) 
says 63
[2019/01/29 10:22:44:4600] INFO: lws_http_action: 0x1861040: LRS_BODY 
state set (0x20000016)
LWS_CALLBACK_HTTP_BODY  13
[2019/01/29 10:22:44:4600] INFO: HTTP_BODY_COMPLETION: 0x1861040 (http)
LWS_CALLBACK_HTTP_BODY_COMPLETION  14
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4600] INFO: lws_issue_raw: ssl_capable_write (233) 
says 233
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4601] INFO: lws_issue_raw: ssl_capable_write (1978) 
says 1978
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4601] INFO: lws_issue_raw: ssl_capable_write (1989) 
says 1989
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4602] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4602] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4603] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4603] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4603] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4604] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4604] INFO: lws_issue_raw: ssl_capable_write (1961) 
says 1961
LWS_CALLBACK_HTTP_WRITEABLE
[2019/01/29 10:22:44:4605] INFO: lws_issue_raw: ssl_capable_write (1960) 
says 1960

-Andy


More information about the Libwebsockets mailing list