[
https://issues.apache.org/jira/browse/TS-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203552#comment-14203552
]
Alan M. Carroll commented on TS-3173:
-------------------------------------
Heh. Maybe we should use a leading '@' to mean "accept but don't advertise" in
the vein of request headers. So "proto=spdy3.1|@spdy3.0" mean "Advertise SPDY
3.1 but accept SPDY 3.1 or 3.0.
We are still left with the issue of enforcing finer grained controls later in
the transaction, specifically the HTTP variants (e.g., don't allow HTTP 0.9 -
we can't do that until we've parsed the request headers).
> Configuration to control list of protocols advertised in the NPN/ALPN list
> --------------------------------------------------------------------------
>
> Key: TS-3173
> URL: https://issues.apache.org/jira/browse/TS-3173
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP, HTTP/2, SPDY
> Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> Currently, {{proxy.config.http.server_ports}} allows to configure
> supported/allowed list of protocols for a given proxy port. The same list
> gets sent as the advertised protocol list in the NPN/ALPN advertisement.
> However, there are situations, where the servers may want the
> allowed/supported protocol list to be different to the npn advertised list.
> For example, you may want to allow http/1.0 for clients not supporting npn
> extensions, but, do not want to advertise http/1.0 in the npn list to prevent
> clients that support npn extension from picking http/1.0.
> As such, I am wondering if we should have a separate control on the npn/alpn
> advertised protocol list.
> If so, please provide comments/suggestions. One straightforward choice is to
> extend the supported parameters for proxy ports (i.e add another parameter
> similar to ":proto"), but, it seems like the configuration becomes more and
> more complex and harder to understand/comprehend.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
