API handling of redirects

[vasilvv]

ietf-wg-webtrans/draft-ietf-webtrans-http3#113 says: "The user agent MUST NOT automatically follow such redirects, as the client could potentially already have sent data for the WebTransport session in question; it MAY notify the client about the redirect."

This is an issue about whether we should, in fact, notify the client about 3xx codes in the API.

[ricea]

In cross-origin contexts we definitely shouldn't, as it would reveal information that would normally be blocked by CORS. For same origin we could, but I don't recommend it. It would encourage people to treat the handshake as a vector for passing information. I would prefer it if they used the WebTransport protocol to exchange info.

[jan-ivar]

It sounds like we're landing on shouldn't? If so,

ietf-wg-webtrans/draft-ietf-webtrans-http3#113 says: "The user agent ... MAY notify the client about the redirect."

...since this spec currently doesn't expose any API for redirects, do we just close this?

[vasilvv]

I think the question was whether we should tell the client we got a 3nn status, or whether we should just return an error.

[jan-ivar]

Short of exposing the url being redirected to, what would an application do with this information?

If the use case is merely debugging, UAs can expose this in web console or hint at it in the message if they want, which this spec would not get involved with.

[jan-ivar]

Meeting:

• useful for debugging
• Do we need an application to take an algorithmic response to a redirect? E.g. go to a different CDN? e.g. for load balancing. We want to support scalable delivery (different mechanisms in use)
• Do we expose:
  1. that we got a 3xx error?
  2. that we got a 3xx error and the redirect url?
• Don't expose in the API?
• Maybe expose just the code, because an app could respond by going down its DNS list? (but would an app limit itself to only taking this action for a confirmed redirect?)
• ACTION: chairs to ask IETF why is redirect in the protocol? What sort of problem did you have in mind for an API to solve?

[wilaw]

Regarding chair action to ask IETF, we are about to enter a recursive loop as it seems that this question was already addressed via ietf-wg-webtrans/draft-ietf-webtrans-http3#61 (comment).

Unless a compelling use-case can be provided for exposing the redirect and given the security concerns, suggestion for workgroup is that we do not notify the client for now. If future use-cases become apparent which require notification, we can extend the spec at that time.

[vasilvv]

The redirect is not intentionally in the protocol, it's just a consequence of it being an HTTP request is that a server can always reply with a 3xx. "3xx is a fatal error just like 5xx would be" is one possible answer.

[jan-ivar]

Meeting:

• No interest in exposing it and no clear use case in doing so.
• We should clarify in our spec that we don't expose this, with a note as to why (echoing API handling of redirects #499 (comment))