Enable rewrite_response to modify status and headers

[ryanlovett]

This builds on @maresb 's work in #209 and enables one to also alter response HTTP headers and status code/reason. Thanks to @yuvipanda for the idea!

[yuvipanda]

can you add tests here for code, headers, etc as well?

[yuvipanda]

Let's add a test, and then we're good to go!

[maresb]

It makes me really nervous to see a mutable object inside a default argument. But in this case I think it's effectively immutable thanks to the lambda.

[maresb]

I really like the extra functionality that this adds, thanks @ryanlovett!

I feel wary about this dictionary and the large number of function arguments flying around, and I wonder if we can do better...

What if we create a RewritableResponse object which is some sort of dataclass with properties request, host, port, path, response, code, reason, headers, and body. Then we can make the rewrite_response function have signature RewritableResponse -> RewritableResponse.

In addition to making the code simpler, this would also make it easy to compose rewrite functions.

[yuvipanda]

While thinking through @maresb's point about unweily arguments, I realized what we should do is use

jupyter-server-proxy/jupyter_server_proxy/utils.py

Line 4 in 5fd3969

def call_with_asked_args(callback, args):

. We use that elsewhere to allow us to add arbitrary args in the future without breaking existing code. So users can request as few or as many args as they want, and we don't need to add extra layers of indirection (like an additional class).

[maresb]

Hmm, I'm quite fond of the ability to chain rewrites in my implementation. Do you see any way to achieve this with call_with_asked_args? It seems to me like it would be much harder that way, but maybe I just haven't thought enough in that direction.

[yuvipanda]

@maresb can you tell me a bit more about what you mean by 'chained rewrites'? An example would be lovely.

[maresb]

@yuvipanda, answered in #301.