Trailers

[mnot]

The defined fields are allowed to be used as trailers. While there might be some use cases where it's necessary, using trailers comes at a cost; some implementations don't expose them, and some intermediary hops will drop them.

So, some advice about their use as trailers should be included, at a minimum. E.g., encouraging their use in headers wherever possible, and warning about the issues with trailers (briefly).

Also, if they're allowed in both headers and trailers, something should be said about what happens when they're in both places -- is that allowed, does one override the other, or are they combined? Keep in mind that 9110 effectively made headers and trailers semantically distinct buckets.

For RateLimit-Policy, what's the use case for putting it in a trailer? Generally, if it's not something that can change while a response is being generated, it should be a header, as that's more interoperable and available.

[ioggstream]

Do you think this matter should be addressed in each field definition or in a specific section (e.g. in Server behavior ) ?

Clarification proposal:

• fields can appear both in header and trailer section
• fields MAY be combined in the header section
• the same field MUST NOT appear at the same time in headers and trailers
• warn that trailers might be dropped by intermediaries

Anyway ff you think there are significant interoperability issues at stake, and since I think that these fields are actually computed before serving, I think it's ok for them to just be headers: there's no implementation afaik that sends these fields as trailers.

[darrelmiller]

For a large or expensive response it might be desirable to include RateLimit-Remaining in a trailer as the current request could have a significant impact on the remaining value.

[mnot]

Right, but the tradeoff is that you have to:

1. document that it might appear in trailers for your API
2. have clients that expect and can process it as a trailer
3. not have any intermediaries in the path that will drop the trailer

[darrelmiller]

If you have the pre-current request remaining value in the header and the post-current request value in the trailer, then clients that do receive the value from the trailer and can process it get a slightly more up-to-date value. To be honest, I 'm not sure it is worth the additional complexity though.