Skip to content

[v0.3] Make (potentially all) headers mutable  #113

Open
@rylev

Description

@rylev

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions