Datagram-Flow-Id is hop-by-hop about masque-drafts HOT 5 CLOSED

I just realized that, because this is a new method and will be treated as such by intermediaries that don't understand it, they will pass Datagram-Flow-Id along. That is very much a bad thing as the server on the next hop might have negotiated H3_DATAGRAM with the intermediary for other reasons. If the next hop understands the setting, it might send responses in datagrams that will then be dropped by the intermediary (because it doesn't understand Datagram-Flow-Id).

That is, on a chain of entities from client A, intermediary B, and intermediary C, if all of them support H3_DATAGRAM, but B does not support Datagram-Flow-Id or CONNECT-UDP, this ultimately results in packets being sent on the request stream for a while, then DATAGRAM frames being sent toward the intermediary and being dropped.

from masque-drafts.

Regarding your first comment, I agree that this is somewhat of a hop-by-hop field. Do you have a proposal that achieves the same result without using a hop-by-hop field?

Regarding your second comment, it's not possible for intermediaries to not understand this and still pass it along. If the intermediary doesn't know about this spec it'll respond with status code 405 "Method Not Allowed" instead of forwarding it.

from masque-drafts.

Proxies aren't required to understand all methods, so why would it send a 405? I mean, some might because they want to police what methods they pass, but they are not required to do so.

from masque-drafts.

Sorry, I should have said 501 "Not Implemented", not 405.

from masque-drafts.

This issue has been moved to the official WG repo

from masque-drafts.