This is the
talk page for discussing improvements to the
HTTP Strict Transport Security article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||
|
The "Overview" section thoroughly describes how a user agent should behave, but says nothing about how the server should behave. A few sentences giving, e.g., the exact header syntax, should make the section complete and not much longer. -- 66.30.251.99 ( talk) 10:47, 29 June 2010 (UTC)
It seems like either the second -if- statement is redundant or -else if- should be replaced with simple -if- 194.105.145.69 ( talk) 07:33, 17 November 2010 (UTC)
In CFML, JSP, VB.NET example - there is no support for SSL-is-used check at all ! That results in else-if branch been always dead code. It better be removed then... Or maybe help requested on artices about JSP, VB.NET, CFML. Note - in above discussion about nested IFs - this mistake been very obvious and just could not slip in ;-) 79.111.223.5 ( talk) 22:50, 14 May 2011 (UTC)
in addition to above, classic ASP does not support request.url (.Net does). 173.9.157.225 ( talk) 00:07, 7 September 2011 (UTC)
FWIW, it's good practice to put an "exit;" after a "header('location: ...');" in PHP - if output buffering is off and any part of the body of the request (e.g. whitespace) has accidentally been sent to the client, I think PHP just gives a warning when you try to redirect via the location header...and then keeps executing code. So your stuff would just go out over http:// in that case. — Preceding unsigned comment added by 74.79.145.8 ( talk) 14:26, 10 September 2011 (UTC)
The plethora of programming languages distracts from the content of the article IMO. Also the redirect instruction doesn't fall within the scope of HSTS IMO. Ben Atkin ( talk) —Preceding undated comment added 17:38, 10 July 2011 (UTC).
I think its relevant Mayhaymate ( talk) 19:20, 3 May 2012 (UTC)
I expanded the applicability section with some information about how this prevents SSL-stripping, and how it should really (or also) be in the DNS records. Please comment/edit rather than just deleting it all! 155.198.65.73 ( talk) 17:36, 22 March 2011 (UTC)
I assume WP:CATALOG #4, #5 is about this list. We should not to list a website ONLY BECAUSE it has HSTS. We can list very famous web-services, such as Gmail, Facebook, Twitter - and the good indication of such is an long-lived article about this service: GMail, Facebook, Twitter. ` a5b ( talk) 18:27, 22 June 2011 (UTC)
The HSTS header can only be sent over SSL. It may be worth mentioning that the attacker could perform a stripping attack to prevent the header from being sent, but I think the sentence should be removed in its current form.-- 79.66.208.193 ( talk) 15:23, 30 August 2011 (UTC)
The article mention of the possibility of using DNSSEC, but it above tell how far the work is on standardizing the use of DNSSEC for this. Kasperd ( talk) 21:23, 25 September 2011 (UTC)
It is possible to deploy HSTS so that a website can be accessed with and without HTTP if wanted and I think this should be added to the article.
I.e. That HSTS is forced only to clients already accessing the site with HTTP with forcing clients that access the site with HTTP to use HTTP. This isnt currently clear and the article gives the impression that using HSTS forces everyone using a website to use HTTP. Mayhaymate ( talk) 11:36, 10 June 2012 (UTC)
Great article but some rather glaring omissions. The browser list doesn't mention IE and the implementation list doesn't mention IIS. There seem to be some other far less prevalent products listed. I wish I could help, but I'm sure someone out there could assist in providing this information for us Microsoft users. — Preceding unsigned comment added by 70.42.29.6 ( talk) 13:07, 15 March 2013 (UTC)
Wget might not qualify as a browser, but version 1.17 and later implement HSTS support. — Preceding unsigned comment added by 107.1.244.230 ( talk) 18:15, 12 May 2017 (UTC)
The RFC does not mention a preload directive or did I miss something? — Preceding unsigned comment added by 77.56.96.22 ( talk) 10:12, 12 March 2015 (UTC)
The second bullet point is a little unclear:
Jimwrightbe ( talk) 15:23, 5 January 2017 (UTC)
The article should not claim or suggest that HTTP is inherently insecure just because it is not encrypted. In case HTTP is inherently insecure, the article needs to explain how and why when suggesting that it is.
It is generally a very bad to give the impression that something which is encrypted is magically secure while something that is not encrypted is magically "insecure". No information and no data is secure, and no encryption is ultimately able to prevent that. — Preceding unsigned comment added by 93.244.198.209 ( talk) 14:09, 2 February 2020 (UTC)