Allow "literal" links

[SenexDemens]

This is based on the experience of not being able to download a pdf file

http://www.satcompetition.org/2011/rules.pdf behind a http:// link because the http:// automatically redirects to the nonexistent https:// link.

There are very many tips of how to deal with that issue, but its complicated and didn't work in my case.

My suggestion would be to easily and temporarily deactive the redirection by providing a means to decalare a link as to be taken "literally", possibly resulting in a dialog with some words of warning.

Maybe prepending the address with something in the vein of "no_https!:http://www.satcompetition.org/2011/rules.pdf "  would be an idea

[Jon]

Thanks for submitting an idea to the Mozilla Connect community! Your idea is now open to votes (aka kudos) and comments.

[cwilby]

I like the text approach.  I can see how having a button would be too "implicit" an action that can too easily be exploited in a MITM style attack.   With that, here are some "unsaids":

1. It should not be possible to craft a link using this proposed style.

<a href="no_https!:http://www.satcompetition.org/2011/rules.pdf"> Click me for prizes! </a>

2. It should probably still come with a security warning the first time it is used, to prevent social engineering attacks that absolutely happen in a large number of organizations.

> Prefixing a URL with no_https!: will explicitly open an insecure version of this link.  You should not use this feature if you are unfamiliar with it's use. Are you sure you want to continue?

[luis123456789]

Note, however, this won't help if the webserver refuses to serve you the direct file. Which is precisely what happens in the example you posted, and what will happen in 90% of the cases because what is gfoing on behind the curtains is a HTTP Redirect.

* Trying to download http://www.satcompetition.org/2011/rules.pdf → HTTP 302 "Found" redirects to the HTTPS version → HTTP 404 error on the HTTPS. The *server* is sending you elsewhere and no matter what your web client does, the server will reply the same way. Note that HTTP 302 means the resource has been moved from the HTTP URL to the HTTPS URL, so your browser ignoring the redirect and trying to continue to fetch the HTTP version not only is an error and disregard of the spec, but also won't work anyway.

Tested this also with CURL and wget, both indicate that the resource has been moved.

[Agentvirtuel]

Hello

For information purposes

https://urlscan.io has analyzed, satcompetition
https://urlscan.io/result/1a49390e-b5e0-4fef-a3ef-de525bbaeea6

---

Submitted URL: http://www.satcompetition.org/2011/rules.pdf
Effective URL: https://satcompetition.github.io//2011/rules.pdf

https://satcompetition.github.io

https://web.archive.org/web/20240000000000*/http://www.satcompetition.org/2011/rules.pdf
https://web.archive.org/web/20230226052400/http://www.satcompetition.org/2011/rules.pdf