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
{{ message }}
Repository navigation
need to define extensibility for alt-svc parameters #69
From discussions in various threads, it is sounding like "must ignore" is a better default behavior for unknown parameters. Otherwise trying to guess which combinations of parameters will cause an AltSvc to be ignored becomes impossibly unwieldy. If "manditory to understand before using a service" parameters are necessary, Martin has the good suggestion of adding a parameter that lists those extension parameters where not understanding them should cause a client to ignore a service. For example a parameter:
must="manditory1,manditory2"
such that:
Alt-Svc: h2=":443"; ma=60; manditory1=1; manditory2="foo"; optional1="bar"; must="manditory1,manditory2"
Would cause the service to be ignored if the client didn't understand manditory1 or manditory2, but optional1 would be ignored if not understood.
Activity
enygren commentedon Jul 2, 2015
From discussions in various threads, it is sounding like "must ignore" is a better default behavior for unknown parameters. Otherwise trying to guess which combinations of parameters will cause an AltSvc to be ignored becomes impossibly unwieldy. If "manditory to understand before using a service" parameters are necessary, Martin has the good suggestion of adding a parameter that lists those extension parameters where not understanding them should cause a client to ignore a service. For example a parameter:
must="manditory1,manditory2"
such that:
Alt-Svc: h2=":443"; ma=60; manditory1=1; manditory2="foo"; optional1="bar"; must="manditory1,manditory2"
Would cause the service to be ignored if the client didn't understand manditory1 or manditory2, but optional1 would be ignored if not understood.
reschke commentedon Jul 17, 2015
I've seen that before in http://greenbytes.de/tech/webdav/rfc2774.html#end-to-end.extensions :-)
mnot commentedon Jul 17, 2015
... which was promptly ignored by the whole world (except for spawning SOAP, and we know how that went...)
mnot commentedon Jul 21, 2015
Discussed in Prague; sense of the room is to have extensibility at the parameter level. Also, sense was to go ahead and establish a registry.
reschke commentedon Sep 1, 2015
So must-ignore-unknown parameters (but process what remains), and add registry, right?
mnot commentedon Sep 2, 2015
yes.
reschke commentedon Sep 2, 2015
"IETF review", I guess? (would be the same as Cache-Control)
mnot commentedon Sep 2, 2015
Let's talk on-list. I think that bar might be a bit high.
reschke commentedon Sep 19, 2015
Changes done in eed78be, let's discuss IANA details separately when needed.
fix change log (#69)