| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When the uwr_get_http_content_str() function, which returns the request
body content as a string, was added it used uwr_get_http_content_len()
to determine the length of the returned string (the request body content
is not null-terminated).
This could potentially in some circumstances return too much data if the
request was split over multiple calls into the Wasm module and
uwr_get_http_content_str() was called before all the data had actually
been received.
Instead use the newly introduced uwr_get_http_total_content_sent()
function to determine the amount of data to return in the string as it
currently stands.
Fixes: bf968c9 ("Rust/rusty: Add uwr_get_http_content_str()")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This returns the total amount of content that the Wasm module has
received so far.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This may not matter in rust (if you use a function before the compiler
has seen a definition for it), but anyway in preparation for adding a
uwr_get_http_total_content_sent() function, put the content length
related functions before the functions that return the content.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This adds the following convenience functions for adding HTTP response
headers, Content-Type & Content-length
uwr_http_add_header_content_type(ctx: *mut luw_ctx_t, ctype: &str);
uwr_http_add_header_content_len(ctx: *mut luw_ctx_t);
These are perhaps the two most common headers so it makes sense to
reduce the effort to adding them.
E.g before
uwr_http_add_header(&ctx, "Content-Type", "text/plain");
uwr_http_add_header(
ctx,
"Content-Length",
&format!("{}", uwr_get_response_data_size(ctx)),
);
after
uwr_http_add_header_content_type(ctx, "text/plain");
uwr_http_add_header_content_len(ctx);
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This function is like uwr_get_http_content() except that it returns a
Rust str.
This is more convenient if you want to operate on the body content
within Rust.
It's worth noting that uwr_get_http_content() returns a non null
terminated buffer which makes it tricky to work with in Rust.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The various uwr_get_ functions should take the context pointer as a
const.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Technically the context pointer can be passed in const even though we
then un-const it passing it to the luw_foreach_http_hdr() macro.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This was used to specify the index of the response header being added,
starting at 0 and incrementing by one for each header.
Instead of having the programmer specify this, track it internally.
We add an extra check in luw_http_add_header() to make sure we aren't
trying to add more headers than we said with luw_http_init_headers(), if
we are, simply return.
This updates the API-C.md and the various examples and 'rusty' API
wrapper.
Suggested-by: Liam Crilly <liam@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This adds a nice wrapper (aka rusty) around the generated libunit-wasm
bindings.
This should provide a more native rust like experience with the
following benefits
- No casting. So no things like 'as *mut c_void'
- Native rust strings. So no things like '.as_ptr() as *const c_char'
- Better ctx initialisation. Filed initialisation is now hidden away
- Great reduction in the amount of unsafe {} blocks required
- Generally more compact
There are also some new macros
- C2S!() converts a CStr to a Str
- S2C!() converts a formatted Str to a Cstr using format!()
- uwr_write_str!() a wrapper around luw_mem_writep_data and format!()
This wrapper uses a uwr (Unit Wasm Rust) prefix under a 'rusty'
namespace.
The luw_http_hdr_iter() function proved tricky to wrap and the callback
function still takes C style arguments due to the fact that this
function is called from the libunit-wasm C library.
The provided wrapper simply means we can use this without having to use
an unsafe {} block around it in application code.
Similarly with other functions that technically didn't need to be
wrapped, wrapping them means that the unsafe {} blocks are hidden away.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
