9

In someone else's code I came across this option setting for cURL:

curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);

The PHP documentation says that by default this option is set to CURL_HTTP_VERSION_NONE which lets cURL decide which HTTP version to use. Otherwise, you can force HTTP 1.0 or HTTP 1.1. Someday there will be the option to force HTTP 2.0 (see this thread on the cURL mailing list: http://curl.haxx.se/mail/lib-2013-09/0020.html)

I am still trying to understand the differences between HTTP 1.0 vs 1.1 from the question HTTP 1.0 vs 1.1 and now I'm wondering what kind of considerations are needed for the future with HTTP 2.0.

My questions are:

  • Is setting the CURLOPT_HTTP_VERSION in an app a good idea if I can't always be sure what HTTP version the server is capable of? Or should I detect the version using $_SERVER['SERVER_PROTOCOL'] and change the CURLOPT_HTTP_VERSION based on that?

  • If I do know the server is capable of HTTP 1.1 (or someday HTTP 2.0) is there any reason to think cURL won't be able to figure this out?

  • Is there a case in which it's better to use HTTP 1.0 rather than HTTP 1.1?

Community
  • 1
  • 1
Sean Fahey
  • 1,850
  • 3
  • 26
  • 36
  • 3
    cURL is smart, let it figure it out. Basically it's going to use the most recent version, and then fail back to the previous if not supported. The differences between HTTP 1.0 and 1.1 are fairly esoteric and seldom matter in the context of a PHP application since apache/nginx/iis/etc handle most everything before the request ever hits PHP. – Sammitch Sep 25 '13 at 22:47

2 Answers2

8

  1. I don't see any benefit. Let curl deal with that.

  2. Curl will do that for you. And I'm pretty sure the future HTTP 2.0 will not break backward compatibility.

  3. As stated in HTTP 1.0 vs 1.1, the only valid reason to prefer HTTP 1.0 is when you cannot send a Host header to the server. But honestly I can't imagine a real world situation.

Community
  • 1
  • 1
voondo
  • 2,533
  • 1
  • 16
  • 21
  • 4
    I just came across a real world scenario. A Squid Proxy (version 3.2) could not correctly handle HTTP 1.1 100-continue responses from the server and hence the client who was sending a HTTP 1.1 PUT (with a HTTP 1.1 `Excpect: 100-continue` header) did receive a `417 Expectation Failed` from the proxy. Forcing curl to use HTTP 1.0 instead worked around this proxy issue. – Sascha Feb 17 '14 at 15:18
  • Had the same issue as @Sascha +1 – GTodorov Oct 19 '17 at 18:47
2

I've got an old PHP application that ran on a server with a version of PHP/libcurl that did not support HTTP 2. It makes requests to an external API and inspects response headers to determine what to do next. But this old code was only designed to handle HTTP 1.0 and HTTP 1.1 headers.

If the application is installed on a server that has HTTP 2 support, curl will choose to use that, and the application will break. So I cannot install it on a newer server, or upgrade the current server, without making code changes.

In this case, changing the application to use HTTP 1.1 (which is known to work) is a much simpler change than changing many parts of the code to inspect a new variety of possible response headers.

Liam
  • 19,819
  • 24
  • 83
  • 123
  • Thanks for the real-world example. Many of us are still dealing when plenty of legacy code from before the time I first asked this question in 2013. Based on the votes that trickle in over the years it is still a relevant issue for some! – Sean Fahey Jan 30 '20 at 15:26