-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protocol: Support for HTTP trailers #141
Comments
I considered adding them into the spec when I was writing it, but as you say, the user agent support is very spotty. ASGI in general is meant to be a spec for "95% of web interactions" (much like WSGI before it), and I think trailers are definitely less than 5% usage out in the wild. If it had any significant usage I'd consider adding it, but as it stands, it's such a specific feature unused by anyone that if someone wants it, they probably want low enough control over HTTP that they need to be doing their own HTTP transport code anyway. Given that, I don't really want to add it into ASGI. |
Yeah, I figured as much. Thanks for giving me the official word on this. |
I've been asked about trailing headers as a Hypercorn issue - do you think it could be supported as an ASGI extension? |
@pgjones If gRPC uses them as that issue suggests, then that would make me think there's some value in adding support. |
This doc may assist: |
It would be great if asgi have grpc support. I'm considering writing an extension for that. Probably like
then use Is it ok to add an extension like this? |
I only just found out HTTP trailers are a thing - I have a few use-cases for them in mind for Datasette now.
|
Trailers are a really, really gnarly part of the HTTP spec, though. I resisted adding them to ASGI for all this time as they're something 99% of applications won't need, and I don't even know if they will work right with proxies (much like why I held out on raw query strings for so long). If we can get some good background information on them being reliably transported, useful enough they're worth implementing, at least one server implementation to say it's not that hard to write, and a decent proposed API for them, then it might make sense to have them in ASGI. |
Well, if you really need that, I have already made a personal fork of hypercorn to support trailers. |
@andrewgodwin Given your last comment, should we reopen this issue? |
Yes, the use of them by GRPC is probably enough of a reason at this point - trust those folks to go resurrect a dusty old part of the HTTP spec :) |
It doesn't seem like the current ASGI specification allows applications to send HTTP trailers in their response, since it is indicated that servers should ignore any further messages on a channel once
mode_body
becomes false in ahttp.response.body
message. This prevents application that stream their content from sending additionnal response information as trailers when it may not be known before the body has begun transfering, regarding things like caching, timing (Server-Timing
), integrity check (Content-MD5
, obsolete), digital signature (Signature
, draft), etc.WSGI doesn't support it and I'm reading that overall support for them in various user agents tends to be flaky most of the time, but I couldn't find any information regarding the omission of trailers from ASGI (whether deliberate or not) and I would like to know if there are any plans to add them at some point in the future, perhaps as an extension.
The text was updated successfully, but these errors were encountered: