[wp-trac] [WordPress Trac] #47577: Streamline detecting and enabling HTTPS

[WordPress Trac]

#47577: Streamline detecting and enabling HTTPS
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion needs-unit-tests has-    |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 @westonruter
 > If a hosted resource is not available on HTTPS (scripts and media), then
 it will fail.

 I'm okay with including `upgrade-insecure-requests`, but your point here
 leads me to believe that we should do a bit more to make sure it doesn't
 break users' sites. How about we also issue a request to a random media
 file, and potentially even a core asset, to make the same check (only if
 the root URL is different, e.g. when using a CDN)? Only if all of them
 support HTTPS, we'll tell the user that their site supports HTTPS. It is
 admittedly a special case, but probably enough people are using a CDN (and
 hopefully they're all good enough to support HTTPS) to make this worth
 having.

 @miinasikk
 > Added the header + also information about `Content-Security-Policy`.

 I'd prefer to not expose this to the user, at least not in here - it's
 very technical information and most folks will have no idea what it is.
 ''If'' we want to expose it, then I'd prefer just doing it in the Info
 part of Site Health, with all the other technical data.

 After reading the previous discussion and reviewing the patch, I'd prefer
 if we just set the `upgrade-insecure-requests` value in the filter and not
 bothered about the very specific `report-only` cases. You'd need to use a
 filter to modify the behavior anyway, and you could just as well remove
 our filter if you wanted to do so. Let's keep the code simple here,
 covering the vast majority of cases. What we should probably do though is
 check, if the `Content-Security-Policy` header is already set, and if so
 append our value (maybe we should even check whether it's not already
 set). We don't wanna override other CSP headers people may be using
 already.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47577#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform