On Thu, 9 Jun 2016, [email protected] wrote:
They both have a cert that covers both hosts and they both share at least
one IP address. And they speak HTTP/2, so in the rare occasion that this
would be a wrong assumption the server can return 421.
Excellent, then please make it to behave exactly the same way with IPv4 only
addresses. Why FF not following the same logic if all IP's are strictly
IPv4 ?
It does. Or perhaps I should say it should, if you indeed can reproduce a
scenario where it doesn't. IP version is not relevant for this context. IP
address overlap is.
Also, let's add to RFC then that all servers must reply with 421 for domains
that are not served as FireFox may decide to contact the server regardless
of IP addresses returned by DNS. Next step will be enforcing the whole world
to implement it.
A) 421 is already in the RFC.
B) It is not at all "regardless of IP address" since, again, both hosts share
IP address(es).
You can't say that correct functionality of host_2 depends of what 3rd party
(administrator of host_1) configured on his server ?
If the hosts indeed are that different as your explained scenario, and handled
by differenent entities, why do they share cert and IP addresses?
But more importantly: why do you think responding with a 421 when this happens
is that wrong?
Quating section 9.1.1 from RFC 7540:
A server that does not wish clients to reuse connections can indicate that
it is not authoritative for a request by sending a 421 (Misdirected Request)
status code in response to the request (see Section 9.1.2).
Surely a compliant HTTP/2 server responds this and then the problem is sorted?
And if you are right and this behaviour is on compliance with RFC, then why
FF is the ONLY browser behaving that way ?
Apart from the mere fact that HTTP/2 is still a fairly new protocol, Firefox
is leading the path in many ways when it comes to HTTP/2 implementations so
there's no surprise that you'll see some behaviors like this in Firefox first.
I think there are reasons to expect others to act similarly in the future.
--
/ daniel.haxx.se
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
