Bugzilla

First of all, , I agree that this change does not fix the actual problem. The original bug description does mention that we are breaking the attack now in the short term, while we are investigating other avenues to fix this long & mid-term.

Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports.
The list of disallowed ports stems back from rather old attacks where nefarious websites could cause a browser to send semi-conformant SMTP or IRC commands through an HTTP POST request. In light of old and new attacks, we won't ever go back to a browser that will allow arbitrary outgoing ports for HTTP requests.

First of all, , I agree that this change does not fix the complete problem. The original bug description does mention that we are breaking the attack now in the short term, while we are investigating other avenues to fix this long & mid-term.

Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports.
The list of disallowed ports stems back from rather old attacks where nefarious websites could cause a browser to send semi-conformant SMTP or IRC commands through an HTTP POST request. In light of old and new attacks, we won't ever go back to a browser that will allow arbitrary outgoing ports for HTTP requests.

First of all, I agree that this change does not fix the complete problem. The original bug description does mention that we are breaking the attack now in the short term, while we are investigating other avenues to fix this long & mid-term.

Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports.
The list of disallowed ports stems back from rather old attacks where nefarious websites could cause a browser to send semi-conformant SMTP or IRC commands through an HTTP POST request. In light of old and new attacks, we won't ever go back to a browser that will allow arbitrary outgoing ports for HTTP requests.

First of all, I agree that this change does not fix the complete problem. The original bug description does mention that we are breaking the attack now in the short term, while we are investigating other avenues to fix this long & mid-term.

Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports. The standard has been fixed and other browsers are implementing this block as well.

The list of disallowed ports stems back from rather old attacks where nefarious websites could cause a browser to send semi-conformant SMTP or IRC commands through an HTTP POST request. In light of old and new attacks, we won't ever go back to a browser that will allow arbitrary outgoing ports for HTTP requests.