| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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 function returns the total amount of content that the Wasm module
has received so far.
This will be used in the rusty API's uwr_get_http_content_str() function
which returns the body content as a string. Due to the body content not
being null-terminated we need to know how much data to use for the
string, for which we are currently using uwr_get_http_content_len(),
which could in some cases return too much if a request is being split
over multiple calls the module.
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>
|
|
luw_http_add_header() no longer takes an idx argument.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
luw_http_add_header() no longer takes an idx argument.
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>
|
|
Bump the version for the 'rusty' API.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Bump the version for the 'rusty' API.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The rust build failed when trying to publish new crates, although for
some reason it didn't fail before that, due to the luw_srb_flags_t enums
generated by bindgen being 32 bit unsigned integers and the flags
argument to luw_set_req_buf() being an unsigned long (which is 64 bits
on my system) and thus producing a type mismatch error.
Rather than fight with rust just make the flags argument an unsigned
int, 32 bits is more than enough for this anyway.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When I added the luw_http_hdr_get_value() function I needed to include
strings.h, unfortunately I added it to unit-wasm.h instead of
libunit-wasm.c
This then meant that we needed to point bindgen/clang, for generating
the bindings, to the wasi-sysroot for the strings.h file. I guess this
is a system dependant include or something and when we use the
wasm32-wasi target in clang it uses a paired down include search path
list, none of which have strings.h
This then had the knock on effect of requiring to inform cargo build of
the wasi-sysroot path.
Now that we put strings.h in the right place, we don't need the
wasi-sysroot when building the rust stuff.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When I added the luw_http_hdr_get_value() function I needed to include
strings.h, unfortunately I added it to unit-wasm.h instead of
libunit-wasm.c
This had the undesirable effect of requiring the wasi-sysroot when
building the rust stuff for generating the libunit-wasm rust bindings.
By including strings.h in the right file we get rid of that requirement
which a subsequent commit will take care of.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
There is no wrapper.h in the repository.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This in preparation for some upcoming changes.
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>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
unit-wasm-sys 0.1.2
Might as well do this now before the code changes and we bump the
version again.
This version was published to crates.io
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
There was a luw_destroy_ctx() function at one point and its prototype
was still in the header file...
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
No reason why this needed to be a separate #define.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
libunit-wasm and example C and Rust WebAssembly modules for NGINX Unit.
Co-developed-by: Timo Stark <t.stark@nginx.com>
Co-developed-by: Liam Crilly <liam@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
