| Summary: | download.eclipse.org/releases/ and download.eclipse.org/technology/ do not upgrade HTTP to HTTPS | ||
|---|---|---|---|
| Product: | Community | Reporter: | Some User <some-eclipse-user-84964571335246229170> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | denis.roy, Ed.Merks, mistria |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=575904 | ||
| Whiteboard: | |||
|
Description
Some User
Also affects http://download.eclipse.org/technology/ (have edited the title of this report accordingly) Or maybe this applies to all (?) subpages of the download.eclipse.org subdomain. For example the 404 page for http://download.eclipse.org/does-not-exist/ does not redirect to HTTPS either. But http://eclipse.org/does-not-exist/ does perform a redirect. I think it's time to simply redirect all d.e.o traffic from HTTP to HTTPS. I've submitted a patch to do that which needs internal review before it goes live. -M. *** Bug 571595 has been marked as a duplicate of this bug. *** (In reply to Denis Roy from comment #4) > *** Bug 571595 has been marked as a duplicate of this bug. *** That report also mentions archive.eclipse.org; will that be redirected as well in the future? Is looks like subpages of www.eclipse.org and eclipse.org are affected in a similar way. Do you want me to create a separate report for this? For example opening http://www.eclipse.org/projects/ or http://eclipse.org/org/workinggroups/ in a new private browser window does not redirect to HTTPS. However, if you had opened eclipse.org using HTTPS in the past, then you are redirected to HTTPS due to HSTS. The patch has been made live so both downloads and archive should now correctly redirect requests to HTTPS. -M. (In reply to Eclipse Webmaster from comment #7) > The patch has been made live so both downloads and archive should now > correctly redirect requests to HTTPS. Thanks for that! |