Https Request Using Net::Http's Block Form -- Is It Possible

HTTPS request using Net::HTTP's block form -- is it possible?

See the documentation for Net::HTTP.start which takes an optional hash. From the documentation:

opt sets following values by its accessor. The keys are ca_file, ca_path, cert, cert_store, ciphers, close_on_empty_response, key, open_timeout, read_timeout, ssl_timeout, ssl_version, use_ssl, verify_callback, verify_depth and verify_mode. If you set :use_ssl as true, you can use https and default value of verify_mode is set as OpenSSL::SSL::VERIFY_PEER.

Net::HTTP.start(url.host, url.port, :use_ssl => true)

Using Net::HTTP.get for an https url

Original answer:

uri = URI.parse("https://example.com/some/path")
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
@data = http.get(uri.request_uri)

As pointed out in the comments, this is more elegant:

require "open-uri"
@data = URI.parse("https://example.com/some/path").read

Ruby: Blocking HTTP.new.start and dynamic HTTP(S)

Per the documentation, you cannot call use_ssl= after starting the session (i.e. after start). You have to set it before, e.g.:

http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true if uri.scheme == 'https'

http.start do |h|
  h.request Net::HTTP::Get.new(uri.request_uri)
end

Make Https call using HttpClient

If the server only supports higher TLS version like TLS 1.2 only, it will still fail unless your client PC is configured to use higher TLS version by default. To overcome this problem, add the following in your code:

System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

Modifying your code example, it would be

HttpClient httpClient = new HttpClient();   

//specify to use TLS 1.2 as default connection
System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

httpClient.BaseAddress = new Uri("https://foobar.com/");
httpClient.DefaultRequestHeaders.Accept.Clear();
httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));
    
var task = httpClient.PostAsXmlAsync<DeviceRequest>("api/SaveData", request);

Request.Form has no value when previous page is a secure page?

The reason is that you use some kind of https to http automatic redirect that is not, and can not handle the post data.

The solution is to direct make the post from https to http page, eg change this:

 PostBackUrl="~/SearchResults.aspx"

to

 PostBackUrl="http://example.com/dir/SearchResults.aspx"

I test that and is working, from one https page post to a new diferent http page.

HTTP GET with request body

Roy Fielding's comment about including a body with a GET request.

Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics.

So, yes, you can send a body with GET, and no, it is never useful to do so.

This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).

....Roy

Yes, you can send a request body with GET but it should not have any meaning. If you give it meaning by parsing it on the server and changing your response based on its contents, then you are ignoring this recommendation in the HTTP/1.1 spec, section 4.3:

...if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

And the description of the GET method in the HTTP/1.1 spec, section 9.3:

The GET method means retrieve whatever information ([...]) is identified by the Request-URI.

which states that the request-body is not part of the identification of the resource in a GET request, only the request URI.

Update

The RFC2616 referenced as "HTTP/1.1 spec" is now obsolete. In 2014 it was replaced by RFCs 7230-7237. Quote "the message-body SHOULD be ignored when handling the request" has been deleted. It's now just "Request message framing is independent of method semantics, even if the method doesn't define any use for a message body" The 2nd quote "The GET method means retrieve whatever information ... is identified by the Request-URI" was deleted. - From a comment

From the HTTP 1.1 2014 Spec:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

Mixed content blocked when running an HTTP AJAX operation in an HTTPS page

If you load a page in your browser using HTTPS, the browser will refuse to load any resources over HTTP. As you've tried, changing the API URL to have HTTPS instead of HTTP typically resolves this issue. However, your API must not allow for HTTPS connections. Because of this, you must either force HTTP on the main page or request that they allow HTTPS connections.

Note on this: The request will still work if you go to the API URL instead of attempting to load it with AJAX. This is because the browser is not loading a resource from within a secured page, instead it's loading an insecure page and it's accepting that. In order for it to be available through AJAX, though, the protocols should match.

Web API Error - This request has been blocked; the content must be served over HTTPS

If your web app is being hosted over HTTPs as you've indicated, then all external resources it is consuming (CDN, scripts, CSS files, API calls) should also use SSL and be secured through HTTPs. Think about it. It would defeat the purpose of your app being secure, if your app was in turn making insecure requests to an API.

You can either therefore:

1. As Chrome suggests, change your API calls to use HTTPs (recommended)

2. Use HTTP instead of HTTPs

3. Add the following meta tag to your <head> element in your HTML:

   <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

More information about this can be found here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests.

---

Related Topics