Clean up minilex
Move the header output to stdout
Introduce lexfile.h as the header output
Use lexfile.h in both minilex itself and lws
Add the following header support
"Accept:",
"If-Modified-Since:",
"Accept-Encoding:",
"Accept-Language:",
"Pragma:",
"Cache-Control:",
"Authorization:",
"Cookie:",
"Content-Type:",
"Date:",
"Range:",
"Referer:"
Signed-off-by: Andy Green <andy.green@linaro.org>
A common practise to temporarily disable a socket in a poll call is to negate the socket fd. poll should then ignore the socket.
emulated_poll does this with the following code:
if (poll_fd->fd < 0 || !poll_fd->events)
goto skip1;
However on Windows the fd field in WSAPOLLFD is unsigned int!!! So the check for a negative fd value always fails.
This results in select returning an error with an error code of 10038 -- Socket operation on nonsocket.
The fix is to type cast fd like so:
if ((int)poll_fd->fd < 0 || !poll_fd->events)
This may be the cause of some high CPU load reports. I noticed the load being 50% with my application running on Windows XP.
Signed-off-by: Graham Newton <gnewton@peavey-eu.com>
This is important since this stuff is in publicly included headers
and even though the usage of the WSAPoll API is a runtime decision
the public headers may be used in code that needs to build with
_WIN32_WINNT=0x0501 to support WinXP.
When building a project using libwebsockets with that define set
to 0x0501 winsock.h will not define the WSAPOLLFD struct causing that
project to fail to compile.
The installed headers are all in the same directory, so no relative
path possible there. The cmake files already add the win32helpers
directory to the include paths, so this builds just fine.
I don't see a wsockcompat.h anywhere in MSVC9 or MSVC8 and their
corresponding sdk's. It does not seem like this is a standard windows
header, so better drop that and add the compat-defines to the same
place that already has other WSA compat defines.
I am using libwebsockets on Windows 7 in external poll mode.
I am finding that if I present a socket fd on a normal HTTP connection
(LWS_CONNMODE_HTTP_SERVING:) to libwebsocket_service_fd with just a HUP
event, the event doesn't get handled but revents gets cleared indicating
that the event has been handled. Should it be handled in the same way
as LWS_CONNMODE_WS_SERVING?
(Modified by AG to apply to all sockets)
Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Graham Newton <gnewton@peavey-eu.com>
Using Windows 7 64 bit, cloned repo on 20130926. Using Qt creator and Microsoft Visual C++ Compiler 9.0 (x86).
Result (errors from compile output): D:\Projects\CDPStudioAPI\libwebsockets_orig\lib\client-handshake.c:87: error: C2065: 'EALREADY' : undeclared identifier
D:\Projects\CDPStudioAPI\libwebsockets_orig\lib\client-handshake.c:87: error: C2065: 'EINPROGRESS' : undeclared identifier
Possible solution is to use wsockcompat.h (compatibility header for using EALREADY, EINPROGRESS etc in older versions of Windows SDK). Compiled fine when I #included wsockcompat.h into client-handshake.c
Reported-by: mart22n via Trac 41
Signed-off-by: Andy Green <andy.green@linaro.org>
A few parameters (like "${PROJECT_BINARY_DIR}/lws_config.h" and "${PROJECT_SOURCE_DIR}/lib") are passed to CMake commands in your build script without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like spaces.
Signed-off-by: Markus Elfring <markus.elfring@web.de>
Subject: [PATCH] We can ran into situation (at least on iOS) when with openssl
nonblocking BIO and http proxy we don't perform ssl_connect straight away so
we need to retry until we finish ssl_connect. If we don't do that we will
fail in LWS_CONNMODE_WS_CLIENT_WAITING_PROXY_REPLY when testing for "HTTP/1.0
200" successful connection.
Signed-off-by: shys <shyswork@zoho.com>
add function to manually setup proxy. Useful on iOS where
getenv doesn't return proxy settings
Simplified by AG
Signed-off-by: shys <shyswork@zoho.com>
Signed-off-by: Andy Green <andy@warmcat.com>
Hi all,
please consider applying the patch below. The git is called in some
different directory and that is why fails. I'm not sure why it was
called in different directory, maybe because I build libwebsockets
with CMake's ExternalProject.
Best,
Arokux
Signed-off-by: Arokux X <arokux@gmail.com>
This patch adds code to handle the situation that a prepared user buffer could not all be sent on the
socket at once. There are two kinds of situation to handle
1) User code handles it: The connection only has extensions active that do not rewrite the buffer.
In this case, the patch caused libwebsocket_write() to simply return the amount of user buffer that
was consumed (this is specifically the amount of user buffer used in sending what was accepted,
nothing else). So user code can just advance its buffer that much and resume sending when the socket
is writable again. This continues the frame rather than starting a new one or new fragment.
2) The connections has extensions active which actually send something quite different than what the
user buffer contains, for example a compression extension. In this case, libwebsockets will dynamically
malloc a buffer to contain a copy of the remaining unsent data, request notifiction when writeable again,
and automatically spill and free this buffer with the highest priority before passing on the writable
notification to anything else. For this situation, the call to write will return that it used the
whole user buffer, even though part is still rebuffered.
This patch should enable libwebsockets to detect the two cases and take the appropriate action.
There are also two choices for user code to deal with partial sends.
1) Leave the no_buffer_all_partial_tx member in the protocol struct at zero. The library will dyamically
buffer anything you send that did not get completely written to the socket, and automatically spill it next
time the socket is writable. You can use this method if your sent frames are relatvely small and unlikely to get
truncated anyway.
2) Set the no_buffer_all_partial_tx member in the protocol struct. User code now needs to take care of the
return value from libwebsocket_write() and deal with resending the remainder if not all of the requested amount
got sent. You should use this method if you are sending large messages and want to maximize throughput and efficiency.
Since the new member no_buffer_all_partial_tx will be zero by default, this patch will auto-rebuffer any
partial sends by default. That's good for most cases but if you attempt to send large blocks, make sure you
follow option 2) above.
Signed-off-by: Andy Green <andy.green@linaro.org>
As spotted by JM on Trac#40
http://libwebsockets.org/trac/libwebsockets/ticket/40
client connect didn't do anything about being truly nonblocking. This patch
should hopefully solve that.
Signed-off-by: Andy Green <andy.green@linaro.org>
''...Websocket servers return failure responses other than HTTP Status 101 in the case of
mismatches of WebSocket version or additional header data etc...
It seems that libwebsockets shows "WARN: problems parsing header" error in such cases without
calling any callbacks or returning error code. Is this right?
I modified lib/client.c to handle this.''
Signed-off-by: Fujii Bunichiroh <Bunichiroh.Fujii@jp.sony.com>
