Description
From this discussion on the v0.3 draft PR @lukewagner said:
#103 is proposes adding a take-headers for extracting headers that become mutable (once they are disconnected from the request/response). Are you taking that addition into account and still it's insufficient? (Alternatively, it seems like we could just make all fields other than Content-Length mutable; the current rules are just trying to be regular, but Content-Length is the only one that really wants the current rules.)
To which @dicej replied:
If I want to pass the original request to the imported wasi:http/handler instead of creating a brand new request and passing that, the only way I can modify headers is if I get mutable access to the headers of the original request (i.e. not a disconnected version), so yes, I think we'd need the mutable-except-for-content-length approach.
Which points to the ability to making headers mutable so that they can changed without having to rebuild request and response objects which could not only be a bit of developer experience issue but also lead to excessive copying.
Additionally, Content-Length
is pointed to as the reason for why headers are immutable in the first place. However, in #105, @lukewagner suggests we want to leave it to guests to set the Content-Length
header correctly.
While messing with Content-Length
header is an easy way to introduce bugs, I don't understand why we fully trust the guest to set the Content-Length
header on request/response construction, but we cannot trust the guest to not mess with the Content-Length
header inappropriately down the line?