HTTP Header in Response exists with a CURL request but not with Browser request

Question

When I run cURL on an object to see its HTTP response headers (I just added agent flag to emulate a browser request):

curl -I -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36" http://b17db03a092ebf708b42-9afd7fe2d9c9c6937aeab44904ac3403.r3.cf5.rackcdn.com/artist/samplesong/13111c20aee51aeb480ecbd988cd8cc9.mp3

I have:

HTTP/1.1 200 OK
Content-Length: 481005
Accept-Ranges: bytes
Last-Modified: Tue, 08 Sep 2015 18:37:54 GMT
ETag: e9f52648c48c707cb9c17e1871787ad8
X-Timestamp: 1441737473.83703
Access-Control-Allow-Origin: *
Content-Type: audio/mpeg
X-Trans-Id: tx6531dbbd8dc541eeaf824-0055f0765eiad3
Cache-Control: public, max-age=259169
Expires: Sat, 12 Sep 2015 18:11:11 GMT
Date: Wed, 09 Sep 2015 18:11:42 GMT
Connection: keep-alive

As you can see, there is a Access-Control-Allow-Origin line.

But when I request the exact same URL with Safari, Chrome or Firefox (without cache):

Accept-Ranges:bytes
Cache-Control:public, max-age=55773
Connection:keep-alive
Content-Length:1
Content-Range:bytes 203184-203184/480621
Content-Type:audio/mpeg
Date:Wed, 09 Sep 2015 18:14:12 GMT
ETag:b1d4c80b2d5d42a4bf6c1ae5efb289e6
Expires:Thu, 10 Sep 2015 09:43:45 GMT
Last-Modified:Mon, 07 Sep 2015 09:19:19 GMT
X-Timestamp:1441617558.54283
X-Trans-Id:txe8e3941ab1774f4d97794-0055ed5c71iad3

Access-Control-Allow-Origin just disappeared !

Any idea why the http response header works with cURL but not with Browser ? Thanks.

Sports

Answer 1

There is no difference between cURL and your browser behaviour.

When you add the -I flag in your curl call, you send a 'HEAD' request. In your browser, it was a 'GET' request.

If you curl this url with the -i flag (-i includes the HTTP-header in the output.), you will lose the "Access-Control-Allow-Origin" line :

curl -i -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36" http://b17db03a092ebf708b42-9afd7fe2d9c9c6937aeab44904ac3403.r3.cf5.rackcdn.com/artist/samplesong/13111c20aee51aeb480ecbd988cd8cc9.mp3 > C:/curl_return.log

And if you open the file you got :

HTTP/1.1 200 OK
Content-Length: 480621
Accept-Ranges: bytes
Last-Modified: Mon, 07 Sep 2015 09:19:19 GMT
ETag: b1d4c80b2d5d42a4bf6c1ae5efb289e6
X-Timestamp: 1441617558.54283
Content-Type: audio/mpeg
X-Trans-Id: tx76217fcbee85481d844ab-0055ed6d83iad3
Cache-Control: public, max-age=56913
Expires: Thu, 10 Sep 2015 10:57:04 GMT
Date: Wed, 09 Sep 2015 19:08:31 GMT
Connection: keep-alive

ID3.................................................................
....................................................................

Quod

It is strange, because I configured it on GET response but I cannot see it. – Sports

Where did you configure it ? In your app or on your server ? – Quod

On rackspace, maybe the problem is coming from rackspace ? – Sports

I really do not know rackspace. But perhaps this will help : #26866130 – Quod

I ended up here from a different problem that also matches the title of this one. In addition to the user-agent, gzip and http version can also be worth trying (curl --http1.1 -H "Accept-Encoding: gzip"). In my case, gzip was breaking on my server but it worked in curl because curl doesn't have gzip enabled by default like browsers do. – Critter

If you curl this url with the -i flag (-i includes the HTTP-header in the output.), you will lose the "Access-Control-Allow-Origin" Is this right? When I tried only when I add -i I get "Access-Control-Allow-Origin" – Bugs