Theoretically speaking, the answer is, of course, "It depends." Practically speaking however, for the client side the answer is "probably not" and the answer for the server side is "yes, with caveats."
This is the situation you're describing. You visit a site with your browser, explicitly specifying the
HTTPS protocol, and are immediately redirected to
HTTP. First, this is not uncommon for news or other content delivery sites. They often do this to take advantage of CDNs and caching options that are not available over
HTTPS in order to reduce the load on the origin servers.
What can you do about it? Not much. Generally this is going to be achived by issuing a 30x location header with the location changed only to modify the protocol to
HTTP. By spec, your user agent is supposed to then navigate to that location. If they are also serving the content in the response body (unlikely) and if you can also induce your user-agent to ignore the location header and not redirect, (not going to happen with a stock browser) then you could theoretically maintain the
HTTPS connection. In reality, they're not going to serve the content and best case is you get an empty response secured by
From the server-side, you have better options. You can do the same thing in reverse, (redirect
HTTP connections to
HTTPS via a location header) disable
HTTP entirely and only allow
HTTPS connections to the server, and you can better enforce
HTTPS-always by using HSTS headers. Big, high value sites (Gmail, for instance) do this with an concept called HSTS preload which is an option compiled into some browsers requiring that any request to the site be converted to
HTTPS before the request is sent. This prevents any information from being accidentally leaked to a MitM even if a user specifically tries to send an
HTTP request. Any site owner, however, can add an HSTS header that tells clients that for some period of time (specified in the header) that client should do the same thing, and only make requests to that domain over
HTTPS, even if the user manually attempts to use
HTTP. This cannot protect the first request, but once the HSTS header has been sent future requests, even requests from future sessions will be protected as the HSTS info will be cached locally by the browser until it expires.