Feature request: in the server, modifying the response headers after they have been sent should raise

[arthurdarcet]

Simple feature: I think after the response has been prepared (ie after the headers are sent back to the client), the Response.headers object should become a read-only dict (ie a CIMultiDictProxy), so that it cannot be modified.

Would you accept a patch doing this?

[asvetlov]

I have no strong opinion.
It makes sense but mutation of attribute type sounds weird from type hinting perspective.

[arthurdarcet]

I agree that the type should stay the same.

Ideally, the response.headers object should be a CIMultiDict, but it should raise exceptions when it is mutated after the headers are sent. Replacing the object with a CIMultiDictProxy achieves that, but will give poor error messages to the users, and breaks the type-hinting. Would you prefer an approach that set headers to be a ResponseHeader object, extending CIMultiDict but with an option to raise an explicit error when trying to use __setitem__, add, pop, popall, … The downside to this is that we will have to maintain here the list of "mutating methods" that are forbidden after the response is sent

[asvetlov]

Let me sleep on it.

[asvetlov]

As an option, we can use multidict's version number: store it on headers sending and compare with the current value on exiting from web-handler.
If numbers are different -- raise a warning or something like this.
Not ideal (no stack trace pointing on the bad code) but better than nothing.

[arthurdarcet]

I think not providing the right stacktrace is a deal breaker, especially when we could provide it. Using a warning instead of making this an error immediately is a good idea of course, to avoid a breaking change

…

On Tue, 4 Sep 2018 at 15:01, Andrew Svetlov ***@***.***> wrote: As an option, we can use multidict's version number: store it on headers sending and compare with the current value on exiting from web-handler. If numbers are different -- raise a warning or something like this. Not ideal (no stack trace pointing on the bad code) but better than nothing. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3231 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7ajj5Kxs9CLzOoV1Pc2ixdeaauhH0vks5uXnnAgaJpZM4WVPRt> .