Hi,
We are running our test suite agains our Cloudflare domain and for some reason we are receiving sometimes the request id header as x-request-id instead of the one returned by our origin server that is X-Request-Id (notice the differences in lowercase letters).
We have re-checked everything and our server is returning without any doubt X-Request-Id.
Any reason why Cloudflare could be modifying/altering this header only sometimes for the same URL?
I haven’t heard of this before. If you look at all the headers, might there be some clue as to what’s different? Do you also see the Cloudflare IP address that’s making the request? (not the visitor’s forwarded IP in the header…I’m just looking for clues as to which Cloudflare node it’s coming through)
This is a response with the unexpected x-request-id in lowercase coming from IP 188.114.111.236:
HTTP/1.1 404 Not Found
Date: Fri, 30 Jul 2021 18:20:02 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 53
Connection: close
x-request-id: d599f1ce-7673-4608-a674-654553a982fb
CF-Cache-Status: DYNAMIC
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=DsJjWMJ4ZALeRsYiO5WUXhX%2BU18OX4A6uBr9rahlj0V%2BGY67wN7Wm8CSJTRRjpbA2aZ61UPw7sjNQYNozlsKX9RWeZZRpp38VJNlgg7RFNKoLymJXLNw%2FZISnyb1SkeE"}],"group":"cf-nel","max_age":604800}
NEL: {"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 67709945abfb14ed-MAD
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400
404: Not found (d599f1ce-7673-4608-a674-654553a982fb)
And this is another one to the same URL but returning the expected X-Request-Id header coming from IP 188.114.111.148:
HTTP/1.1 404 Not Found
Date: Fri, 30 Jul 2021 18:17:13 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 53
Connection: close
X-Request-Id: 4c0da5a1-b732-4a38-8907-b27f7166b29a
CF-Cache-Status: DYNAMIC
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=wpzYIjbW%2FwQ6iLBwRVOXsA8faRrqnmL4%2FN0NrnmIVon1SPBKVFIqY%2BdPF1a0JjT%2BobcGN7UGd8hHCAEqqWvVl9wHK2kfXel6QyNhJFOdwcRJgdi2H5qityLf7pPn2deB"}],"group":"cf-nel","max_age":604800}
NEL: {"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 6770952548651501-MAD
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400
404: Not found (4c0da5a1-b732-4a38-8907-b27f7166b29a)
Thanks for your help.
Well, shoot. Same datacenter, and I don’t see any other reason for the difference.
Can you open a ticket and post the # here? EMail them at: support AT cloudflare DOT com (from your account’s email address).
Done, the id is #2219361
The ticket looks like solved (with a bot response linking me here to the community). Tell me if that can be a problem.
Thanks for your help again.
Reply to the ticket and say the headers are still inconsistent and include a link to this thread (if you didn’t already do that). That should re-open it.
Meanwhile, I’ll push this into the escalation queue.
Done but the bot is replying again and the state didn’t change 
Tell me if I can do any other thing.
I already escalated, but for fun, you can reply again and say you need more help. I’d be curious to hear how many replies it takes for it to not slam the ticket closed on you.
HTTP Headers are not case sensitive. (But I would apply Postels Law in any case.)
In HTTP/2, all header fields should be lower case, so CF are probably doing the case conversion.
…sometimes. But why the inconsistent behavior? I was hoping to find a feature that would “normalize” headers, but can’t find anything except for Workers, which is overkill.
@michael may be onto something here, as I can only replicate this when sending a curl in HTTP/1.1:
> GET / HTTP/1.1
> Host: cdn.i********
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Tue, 03 Aug 2021 17:03:41 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 53
< Connection: keep-alive
< X-Request-Id: 767b322a-f6cf-..................
< CF-Cache-Status: DYNAMIC
I could not reproduce even after many curl retries with HTTP/2:
> GET / HTTP/2
> Host: cdn.i********
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 404
< date: Tue, 03 Aug 2021 17:04:58 GMT
< content-type: text/plain; charset=utf-8
< content-length: 53
< x-request-id: cf413a6e-d...................
< cf-cache-status: DYNAMIC
Out of curiosity, is this causing any type of issues with your server/site?
My hunch is that you may be seeing the inconsistency due to HTTP and HTTPS requests being sent to your server.
Take a look to my previous comments, it’s happening to me with HTTP/1.1 request.
Not exactly, we have a complete suite of tests that checks a lot of things for our application, one of those things is to check that expected headers are included in the response and those checks are done in a case-sensitive way so our test suite is failing for that reason.
We know that headers are case-insensitive in the HTTP specification but I would like to understand the reason behind this inconsistency.
We have other cases were headers dissapear completely, for example we are responding with Vary headers in some scenarios and those appear only sometimes in the Cloudflare response.
Thanks for your help.
With HTTP/1.1 it is not a requirement that HTTP responses headers be lowercase where it is in HTTP/2. I’d suggest only using http/2 requests if this consistency is needed in your application, or dropping the requirement if possible.
Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. A request or response containing uppercase header field names MUST be treated as malformed (Section 8.1.2.6).
I found this Stack Overflow discussion helpful but note the key aspect here:
“However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2.”
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.