Talk:HTTP Strict Transport Security

What is the exact response header?

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)

I agree. -- Kistano (talk) 23:19, 5 September 2010 (UTC)

Please, check the code

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)

The second -if- statement is meant to redirect users not using HTTPS already, however, in many of the snippets there is no check for this. Code needs work. --praseodym (talk) 16:53, 26 February 2011 (UTC)

That better be without AND at all. Skeleton is to be nested IFs: IF [ STS-a-must] THEN [ if { SSL-is-used } then {add-STS-header} else { redirect-to-SSL } ] ELSE [ ...non-STS path... ]

However, the code is just broken

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)

Why so many code examples?

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 relevantMayhaymate (talk) 19:20, 3 May 2012 (UTC)

Applicability

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 . 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)

"Of course, the HSTS header can be stripped by the attacker if this is the user's first visit."

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)

Agreed. The current wording is self-contradictory. A more correct description of the attack would be to use an SSL stripping to prevent the header from being communicated to the client. Kasperd (talk) 21:23, 25 September 2011 (UTC)

Use of DNSSEC

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)

Use of HSTS without forcing all clients to use HTTP should be added

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)

Browser Support and Implementation

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)

preload directive?

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)

Deployment Best Practices

The second bullet point is a little unclear:

• I assume it should say something like "In addition to HSTS deployment, pages served by https://www.example.com should trigger a browser request to https://example.com ..." then I guess it might go on to suggest loading an empty javascript file or hidden image?
• A source should be cited. (I have since found it under External Links but am not sure how to cite it: The State of HSTS Deployment: A Survey and Common Pitfalls) I have not found evidence of major sites implementing this (including icloud.com referenced in the source) so maybe it is outdated somehow or not necessary once a domain is in the preload list.

Jimwrightbe (talk) 15:23, 5 January 2017 (UTC)

In which way is HTTP insecure?

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)