| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
Also, nng_err is now a distinct type which might be nicer in debuggers.
|
| |
|
|
|
|
|
| |
We want to consume the request properly on an error, so that
we can give a reasonable response. We were prematurely closing
the connection for certain failure modes. We still have to fix
overly long URIs and headers, but thats next!
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The body content not being consumed was leading to misparses, where
we consumed body data as if it were a request. When mixed with proxies
this could lead to a security problem where the following request
content submitted from a different client winds up as stolen request
body content.
This also ensures we actually deliver errors to clients without
prematurely closing the connection. (There are still problems
where the connection may be closed prematurely for an overlarge
header.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This represents a major change in the HTTP code base, consisting
of a complete revamp of the HTTP API. The changes here are too
numerous to mention, but the end result should be a vastly
simpler API for both server and client applications.
Many needless allocations were removed by providing fixed buffers
for various parameters and headers when possible.
A few bugs were fixed. Most especially we have fixed some bugs
around very large URIs and headers, and we have also addressed
conformance bugs to more closely conform to RFCs 9110 and 9112.
As part of this work, the APIs for WebSockets changed slightly
as well. In particular the properties available for accessing
headers have changed.
There is still documentation conversion work to do, and additional
functionality (such as proper support for chunked transfers), but
this is a big step in the right direction.
|
| |
|
|
|
|
|
|
|
|
| |
This simplified API lets callbacks obtain the response from the
connection objection directly, and does not require the aio to carry
it as a parameter. Further, the request and response are both
stored inline in the connection, reducing allocations.
This is at present only for the server; the client will get a similar
set of changes.
|
| |
|
|
|
| |
This is a step towards simplifying this API and ultimately simplifying
the HTTP callback API used for the server side.
|
| |
|
|
|
| |
This is a recent regression that affects any server that does not
explicitly set an HTTP status code.
|
| | |
|
| |
|
|
|
| |
This saves yet another allocation. It also no longer returns a value
making this a breaking change.
|
| |
|
|
|
|
| |
There are only a few possible reasonable values, and we can intern
them to avoid any allocations for it. (We will probably do the same
for the HTTP method shortly as well.)
|
| |
|
|
| |
This should simplify debugging in some circumstances.
|
| | |
|
| |
|
|
| |
the separation of nni_url and nng_url.
|
| |
|
|
|
|
|
| |
This eliminates most (but not all) of the dynamic allocations
associated with URL objects. A number of convenience fields
on the URL are removed, but we are able to use common buffer
for most of the details.
|
| |
|
|
|
|
|
|
|
|
|
| |
The idea here is to reduce the dynamic allocations used for
URLs, and also the back and forth with parsing begin strings
and port numbers. We always resolve to a port number, and
this is easier for everyone.
The real goal in the long term is to eliminate dynamic allocation
of the URL fields altogether, but that requires a little more
work. This is a step in the right direction.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
fixes #718 http_transact is still not right
fixes #719 calculation of buffer size is incorrect in http
|
| | |
|
| |
|
|
|
| |
This adds a couple of new methods, and related documentation
and test cases.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We move the HTTP definitions out of the core nng.h and into
a supplemental header. Most of this change was trivial updates
to all of the HTTP related manual pages.
|
| |
|
|
|
| |
This member is the value passed in actual HTTP protocol, so it
is useful with the function nng_http_req_set_uri().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces enough of the HTTP API to support fully server
applications, including creation of websocket style protocols,
pluggable handlers, and so forth.
We have also introduced scatter/gather I/O (rudimentary) for
aios, and made other enhancements to the AIO framework. The
internals of the AIOs themselves are now fully private, and we
have eliminated the aio->a_addr member, with plans to remove the
pipe and possibly message members as well.
A few other minor issues were found and fixed as well.
The HTTP API includes request, response, and connection objects,
which can be used with both servers and clients. It also defines
the HTTP server and handler objects, which support server applications.
Support for client applications will require a client object to be
exposed, and that should be happening shortly.
None of this is "documented" yet, bug again, we will follow up shortly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a problem where the websocket would only send one message,
then no others, due to not clearing the "frame" busy flag on completion
of the frame transmit.
We have also added a test that tries to send 10 messages back and
forth to make sure that we catch this kind of problem in the future.
Finally we've fixed some problems that were found when testing edge
cases around the protocol, which were responsible for invalid memory
accesses.
|
| | |
|
| | |
|
|
|
This is a rather large changeset -- it fundamentally adds websocket
transport, but as part of this changeset we added a generic framework
for both HTTP and websocket. We also made some supporting changes to
the core, such as changing the way timeouts work for AIOs and adding
additional state keeping for AIOs, and adding a common framework for
deferred finalization (to avoid certain kinds of circular deadlocks
during resource cleanup). We also invented a new initialization framework
so that we can avoid wiring in knowledge about them into the master
initialization framework.
The HTTP framework is not yet complete, but it is good enough for simple
static serving and building additional services on top of -- including
websocket. We expect both websocket and HTTP support to evolve
considerably, and so these are not part of the public API yet.
Property support for the websocket transport (in particular address
properties) is still missing, as is support for TLS.
The websocket transport here is a bit more robust than the original
nanomsg implementation, as it supports multiple sockets listening at
the same port sharing the same HTTP server instance, discriminating
between them based on URI (and possibly the virtual host).
Websocket is enabled by default at present, and work to conditionalize
HTTP and websocket further (to minimize bloat) is still pending.
|
