http-headers to - View HTTP headers in Google Chrome?
network tools (6)
I'm not sure about your exact version, but Chrome has a tab "Network" with several items and when I click on them I can see the headers on the right in a tab.
Press F12 on windows or ⌥⌘I on a mac to bring up the Chrome developer tools.
Till 9.x, the headers were under the resources in the Developer Tools, but now I can't find it anywhere.
My favorite way in Chrome is clicking on a bookmarklet:
Put this code in your developer console pad.
I loved the FireFox Header Spy extension so much that i built a HTTP Spy extension for Chrome. I used to use the developer tools too for debugging headers, but now my life is so much better.
Here is a Chrome extension that allows you to view request-, response headers and cookies without any extra clicks right after the page is loaded.
It also handles redirects. It comes with an unobtrusive micro-mode that only shows a hand picked selection of response headers and a normal mode that shows all the information.
For me, as of Google Chrome Version 46.0.2490.71 m, the Headers info area is a little hidden. To access:
1)While the browser is open, press F12 to access Web Developer tools
2)When opened, click the "Network" option
3)Initially, it is possible the page data is not present/up to date. Refresh the page if necessary
4)Observe the page information appears in the listing. (Also, make sure "All" is selected next to the "Hide data URLs" checkbox
I know there is an accepted answer but I recommend
Simple REST Client Extension for Chrome.
On June 2012, the deprecation of recommendation to use the "X-" prefix has become official as RFC 6648. Below are cites of relevance:
3. Recommendations for Creators of New Parameters
- SHOULD NOT prefix their parameter names with "X-" or similar constructs.
4. Recommendations for Protocol Designers
SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered.
MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.
MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized.
Note that "SHOULD NOT" ("discouraged") is not the same as "MUST NOT" ("forbidden"), see also RFC 2119 for another spec on those keywords. In other words, you can keep using "X-" prefixed headers, but it's not recommended and you may not document them as if they are public standard.
On June 2011, the first IETF draft was posted to deprecate the recommendation of using the "X-" prefix for non-standard headers. The reason is that when non-standard headers prefixed with "X-" become standard, removing the "X-" prefix breaks backwards compatibility, forcing application protocols to support both names (E.g,
gzip are now equivalent). So, the recommendation is to just name them sensibly without the "X-" prefix.