AG: added changelog and documentation comment
Signed-off-by: Gadkari Mugdha <mugdha.gadkari@siemens.com>
Reviewed-by: Roger Meier <r.meier@siemens.com>
HTTP reject error code returned by server during HTTP handshake is extracted and sent to the client application.
With this fix, the Connection error callback will include the HTTP reject status code and response frame received from server. This string passed in Connection error callback can be read or ignored by client application based on client application requirement
merged by andy@warmcat.com via https://github.com/gaby64/libwebsockets-libev
To use, you need to both
- cmake ---> -DLWS_USE_LIBEV=1
- info->options must have LWS_SERVER_OPTION_LIBEV set when creating the context
this is so a single library can be built for distros to support apps that use
normal polling and apps that use libev polling.
This adds two new callbacks in protocols[0] that are optional for allowing limited thread
access to libwebsockets, LWS_CALLBACK_LOCK_POLL and LWS_CALLBACK_UNLOCK_POLL.
If you use them, they protect internal and external poll list changes, but if you want to use
external thread access to libwebsocket_callback_on_writable() you have to implement your
locking here even if you don't use external poll support.
If you will use another thread for this, take a lot of care about managing your list of
live wsi by doing it from ESTABLISHED and CLOSED callbacks (with your own locking).
Signed-off-by: Andy Green <andy.green@linaro.org>
If enabled one listening socket will accept both SSL and plain HTTP connections.
Do not enable if you regard SSL handshake as some kind of security, eg, use
client-side certs to restrict access.
AG: changed flag names, added extra comments, changelog, add -a in test server
Signed-off-by: James Devine <fxmulder@gmail.com>
Signed-off-by: Andy Green <andy@warmcat.com>
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>
under load, writing packet sizes to the socket that are normally fine
can do partial writes, eg asking to write 4096 may only take 2800 of
it and return 2800 from the actual send.
Until now lws assumed that if it was safe to send, it could take any
size buffer, that's not the case under load.
This patch changes lws_write to return the amount actually taken...
that and the meaning of it becomes tricky when dealing with
compressed links, the amount taken and the amount sent differ. Also
there is no way to recover at the moment from a protocol-encoded
frame only being partially accepted... however for http file send
content it can and does recover now.
Small frames don't have to take any care about it but large atomic
sends (> 2K) have been seen to fail under load.
Signed-off-by: Andy Green <andy.green@linaro.org>
More flexible this way... NULL for the new member means use
the ssl library default set of ciphers, so as long as your info
struct is zerod by bss or memset, you don't need to do anything
about this change unless you want to set the cipher list.
Signed-off-by: Andy Green <andy.green@linaro.org>
To get a clean bill of health from valgrind, we have to have a way to
inform the user code that we're going down and it should free everything
it is holding that was malloc'd.
This patch introduces LWS_CALLBACK_PROTOCOL_DESTROY which each protocol
gets when the context is being destroyed and no more activity will come
after that call. They can get rid of everything there.
To match it, LWS_CALLBACK_PROTOCOL_INIT is introduced which would allow
one-time init per protocol too.
Signed-off-by: Andy Green <andy.green@linaro.org>
This big patch replaces the malloc / realloc per header
approach used until now with a single three-level struct
that gets malloc'd during the header union phase and freed
in one go when we transition to a different union phase.
It's more expensive in that we malloc a bit more than 4Kbytes,
but it's a lot cheaper in terms of malloc, frees, heap fragmentation,
no reallocs, nothing to configure. It also moves from arrays of
pointers (8 bytes on x86_64) to unsigned short offsets into the
data array, (2 bytes on all platforms).
The 3-level thing is all in one struct
- array indexed by the header enum, pointing to first "fragment" index
(ie, header type to fragment lookup, or 0 for none)
- array of fragments indexes, enough for 2 x the number of known headers
(fragment array... note that fragments can point to a "next"
fragment if the same header is spread across multiple entries)
- linear char array where the known header payload gets written
(fragments point into null-terminated strings stored in here,
only the known header content is stored)
http headers can legally be split over multiple headers of the same
name which should be concatenated. This scheme does not linearly
conatenate them but uses a linked list in the fragment structs to
link them. There are apis to get the total length and copy out a
linear, concatenated version to a buffer.
Signed-off-by: Andy Green <andy.green@linaro.org>
The idea here seems wrong, if we have a mixture of frames of varying
sizes above and below the limit, we segfault in deflate after skipping
it once.
If the protocol doesn't want compression because many frames are
small, it should veto the extension in the user callback. If only
a few frames are tiny, the overhead for compressing it all is tiny.
Signed-off-by: Andy Green <andy.green@linaro.org>
Now we are building with -O0 -g and debug enabled by default.
--disable-debug in configure will get you a -04 without -g
Signed-off-by: Andy Green <andy.green@linaro.org>
*** This patch changes an API all apps use ***
Context creation parameters are getting a bit out of control, this
patch creates a struct to contain them.
All the test apps are updated accordingly.
Signed-off-by: Andy Green <andy.green@linaro.org>
A new protocol member is defined that controls the size of rx
buffer allocation per connection. For compatibility 0 size
allocates 4096, but you should adapt your protocol definition
array in the user code to declare an appropriate value.
See the changelog for more detail.
The advantage is the rx frame buffer size is now tailored to
what is expected from the protocol, rather than being fixed
to a default of 4096. If your protocol only sends frames of
a dozen bytes this allows you to only allocate an rx frame
buffer of the same size.
For example the per-connection allocation (excluding headers)
for the test server fell from ~4500 to < 750 bytes with this.
Signed-off-by: Andy Green <andy.green@linaro.org>
