Closed hishamhm closed 6 months ago
Merging #532 (be79467) into main (7ee4eb4) will decrease coverage by
0.00513%
. The diff coverage is94.33962%
.
Before merging this (I have not made any changes yet locally), I think we should add context checks for set_response_header
to better capture which phases the function can be called from (and :status
be set from, particularly). These context checks go in t/03-proxy_wasm/hfuncs/contexts
.
I think we should add context checks for set_response_header to better capture which phases the function can be called from (and :status be set from, particularly).
@thibaultcha How hard should the context checks be? In the current code, headers being set in the wrong context are soft errors, and bodies being set in the wrong context are hard errors.
For headers, functions such as ngx_proxy_wasm_hfuncs_replace_header_map_value
and ngx_proxy_wasm_hfuncs_set_header_map_pairs
return OK and just log an error when attempting to set response header when the headers are already sent.
For bodies, in ngx_proxy_wasm_hfuncs_set_buffer
, attempting to set the response body or request body from the wrong place trigger a trap.
To clarify, by "add context checks" are you suggesting we turn the header checks mentioned above into hard errors?
@thibaultcha is this second commit 6014ff0 what you had in mind?
Yes, strengthen our context checks and formalize the behavior in each unsupported phase. Regarding the tests themselves, setting a response header in the request phases will not have any effect so I think we should catch usage there is what I meant, cutting some decisions where the behavior is "strange" or "undefined". For example, the new :status
pseudo-header may work when used from the request phases(?), but that's different from pure response headers (or special response headers)... As this adds more behavior into the response headers, I think we should cover expected cases and make some decisions wherever we have margin (do we allow usage or not, how consistent are we between use-cases or sister APIs like set_body
, etc...).
@thibaultcha The added context checks and tests should be ready for review now!
Thanks! The code etc all looks good; I'll just reorganize the tests to try not to duplicate test cases between hfuncs/
and hfuncs/contexts
(also the contexts tests are supposed to be non-functional - only test the return code - but maybe they should be to avoid confusion, I'll compare with the other suites).
Thanks! I did notice some duplication there, but when in doubt I added stuff to both, just in case. The main difference I could spot is that hfuncs/contexts
tests are using context-checks
which is testing at the extern "C"
low-level (e.g proxy_set_buffer_bytes
), and the ones in hfuncs/
are using proxy-wasm-rust-sdk (e.g. ctx.set_http_response_headers
).
Since #484, we now have an easy way to implement support for setting the ":status" pseudo-header.