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
http protocol should support the content/accept encoding headers so that http clients which can and want to use compression when interacting with the server may do so.
where should the encoding happen? the obvious place would be when we finish parsing the request stream. the problem there is that that's on the main serving thread and would block request processing for other multiplexed requests. the best place then would be right before the request is worked on. the problem there is that the worker APIs are protocol agnostic. what this means is that the application which has the burden of knowing what protocol it's working on will.have to initiate the encoding. we have another problem though then which is that the pipeline can have multiple stages so the encoding needs to only happen at the last stage. again the application controls that so it will also know when it's even appropriate to check the encoding.
seems to me we should add some functions to the http request/response protocols to automatically handle this and modify the body contents and length amd encoding headers. a little bit of thought is needed to determine the most ergonomic way to do that though it seems doable
The text was updated successfully, but these errors were encountered:
http protocol should support the content/accept encoding headers so that http clients which can and want to use compression when interacting with the server may do so.
where should the encoding happen? the obvious place would be when we finish parsing the request stream. the problem there is that that's on the main serving thread and would block request processing for other multiplexed requests. the best place then would be right before the request is worked on. the problem there is that the worker APIs are protocol agnostic. what this means is that the application which has the burden of knowing what protocol it's working on will.have to initiate the encoding. we have another problem though then which is that the pipeline can have multiple stages so the encoding needs to only happen at the last stage. again the application controls that so it will also know when it's even appropriate to check the encoding.
seems to me we should add some functions to the http request/response protocols to automatically handle this and modify the body contents and length amd encoding headers. a little bit of thought is needed to determine the most ergonomic way to do that though it seems doable
The text was updated successfully, but these errors were encountered: