You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current WIT definitions, outgoing-bodyfinish defines that the content length must be validated against the actual length.
But, in addition to this, the Wasmtime implementation also throws a stream error from the output-stream for the outgoing-body as soon as a write is made that exceeds the expected content length. Thus this check is not only performed at finish but also dynamically with each write operation to the stream.
If this is the defined behaviour, it should be documented in the WIT.
The text was updated successfully, but these errors were encountered:
Agreed we should document this on outgoing-body.write!
One way to implement this is for check-write to refuse readiness once the content-length has been reached, but this is difficult to debug because blocking-write would loop forever, or have to trap.
Instead we should specify that check-write may allow writes beyond the content-length, but if those writes are performed, write (or blocking-write or blocking-write-and-flush) will throw a last-operation-failed that will downcast to a HTTP-{request,response}-body-size.
In the current WIT definitions,
outgoing-body
finish
defines that the content length must be validated against the actual length.But, in addition to this, the Wasmtime implementation also throws a stream error from the
output-stream
for theoutgoing-body
as soon as a write is made that exceeds the expected content length. Thus this check is not only performed atfinish
but also dynamically with each write operation to the stream.If this is the defined behaviour, it should be documented in the WIT.
The text was updated successfully, but these errors were encountered: