I am attempting to insert a custom response header to comply with a requirement to enable HSTS as the current layout is at risk against our cyber security audit.
I am referencing this previous StackOverflow thread as the "best answers" suggests to set the custom response header using the IIS7 Manager interface, versus the second "best answer" to be going into the web.config file and copy and pasting code into it.
I tried to follow directions to access using this link, but I did not get far because I do not have EFTAdHoc subfolder under Default Web Site on step 3.
I am curious if it is still ok if I set the custom response header this way:
I am curious if it is still ok if I set the custom response header this way:
This dialogue is adding headers for all requests. But in your case, you need slightly different. You need to add HSTS only for HTTPS requests. Answer in this thread which you referred before is correct because it is setting header only if it is HTTPS request.
You can do that with IIS Manager.
1) Go to URL Rewrite
2) Click Add Rule -> Outbound rules -> Blank rule
3) Fill fields like that:
Just curious, I can see some http2 pseudo headers fields like :method,
:scheme,:authority when I go to some website that has enabled http2.
Example, for homepage of www.ft.com, there are these pseudo request headers:
:authority:www.ft.com
:method:GET
:path:/
:scheme:https
Is it possible to read/modify those fields in chrome extension, just like we can read/modify Cookie, Referer, User-Agent?
Or if it is not possible in chrome, can we do it in other browsers like firefox?
So all HTTP/2 headers start with a : (to distinguish them from HTTP/1.x headers)
Not aware of any extensions to alter them, but I guess the real question is why would you want to?
I have my api running on node js, where for security reasons, I have set up a middle ware function check the origin header, if it is from my website, then only the api should go ahead. I am finding issues with Chrome Extension, as it does not pass the origin header in the get requests, also in the put requests, it sends something like chrome:// as the origin header. Can somebody help?
Regards,
Manik Mittal
Well, that's how Chrome sets the Origin for extensions. It's not simple to override.
It is, however, possible to override. You'll need to use the webRequest API, specifically a blocking response to onBeforeSendHeaders, to rewrite the origin to whatever you like.
If you add in your manifest.json "permissions": ["https://*/"] you shouldn't have problems with CORS. Or if you want only your API to avoid this, just add your own url.
I faced a problem.
When you add multiple Set-Cookie headers to the response
headers.Add("Set-Cookie", "a=b;Path=/;");
headers.Add("Set-Cookie", "c=d;Path=/;");
actually they are combined and only one header is sent with comma-separated cookies
Set-Cookie: a=b;Path=/;,c=d;Path=/;
According to RFC2109 it is a valid syntax.
But it is not according to RFC6265, which deprecates RFC2109
Moreover latest browsers does not support this comma-separated syntax as well. Tested on IE9, Firefox 13 and Google Chrome 20.
All of these browsers took first cookie only.
Please see the sample project below
https://github.com/mnaoumov/cookie-bug/
I want to find some workaround.
I expect to have two different Set-Cookie headers.
I tried to write some MessageInspector to rewrite HTTP headers. I could not find how to access that headers.
Any ideas?
P.S. Used technology: Web API
According to answer on codeplex (http://aspnetwebstack.codeplex.com/workitem/288) this issue is known issue and related to WCF self-hosting and should be fixed by moving to IIS hosting.
This is WCF 4 issue which marked as won't fix.
Found another question with the same outcome WCF 4.0 Cookie Only First is Recorded by Browser.
You can use the HttpContext.Current.Response.SetCookie
using System.Web;
HttpCookie foo = new HttpCookie("foo", "true");
HttpContext.Current.Response.Cookies.Add(foo);
HttpCookie bar = new HttpCookie("bar", "true");
HttpContext.Current.Response.Cookies.Add(bar);
This will add multiple set-cookies header in the response.
Edit: also, you should add the
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true"/>
in your web.config
Traditionally, I would inspect the Akamai headers by installing a Firefox extension called akamaiheaders.xpi. Unfortunately, I think the last version of Firefox to support this was 3.
As I understand it, this plugin would add special headers to all HTTP requests that Firefox made, which would prompt Akamai to add a bunch of headers to the response (telling me whether the file was cached, where it got it from, etc.). Then, using a tool like HTTPFox or Firebug, I could easily see which assets were cached and which ones were not.
I've searched all over, but I can't find anything as simple and easy to use as that. Does anyone know of anything out there that allows me to track all the Akamai headers for all the assets my browser loads that works in either FF, Chrome, or Safari?
You can use curl and/or wget for this:
curl -H "Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no" -IXGET http://www.oxfordpress.com/
or
wget -S -O /dev/null --header="Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no" http://www.oxfordpress.com/
If you want to test staging environment, you need to remember to send Host header, eg:
curl -H "Host: www.oxfordpress.com" -H "Pragma: ..." -IXGET http://oxfordpress.com.edgesuite-staging.net/
This way or another, it's always about sending proper Pragma headers and then reading response headers.
List of Pragma headers as well as explanations for X-Cache response header can be found here: http://webspherehelp.blogspot.com/2009/07/understanding-akamai-headers-to-debug.html.
I know this question is old, but since I came across it in my search today I thought I'd add an answer for the next person who comes along.
There are a couple of extensions in the Chrome store for this now:
Akamai debug headers which just adds headers to your net panel in web inspector
Exceda Akamai Headers Extension which seems to also work for purging cache.
Akamai debug headers is the one I chose and it's working well so far.
You can use a local proxy (e.g. Fiddler or Charles Proxy, my personal favorite) and add the following header to outgoing requests:
Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no
If you're using Chrome or Chromium, you can use the extensions Header Hacker or Pragma Header. With either one, you will be have to add Pragmas manually.
If you can find the akamaiheader.xpi file, you can just open it and change the maxVersion in install.rdf to 9.*
.xpi files are just ZIP files, and on most machines you can just add .zip to the filename and doubleclick on it.
To debug akamai headers, for the Chrome browser, try this extension: CDN Headers & Cookies - Chrome Web Store
https://chrome.google.com/webstore/detail/cdn-headers-cookies/obldlamadkihjlkdjblncejeblbogmnb
Note: Enable 'Load Akamai Headers' in the settings (click the 'Lego minifig Head' icon, click the gear, and check on 'Load Akamai Headers').
It has been suggested on the Akamai community.
https://community.akamai.com/community/web-performance/blog/2015/03/31/using-akamai-pragma-headers-to-investigate-or-troubleshoot-akamai-content-delivery
They have a new version of the XPI out which you can download in Luna. There's also another Plugin which adds a 'content source' pane into Firebug for a quick reference of what on the page was Akamaised.
As I say, to download both plugins you need to login to Luna and look under 'Support' > 'More Tools' > 'Browser Extensions'. The XPI isn't publicly accessible.
YMMV but as far as I recall being told by colleagues the Exceda plugin duplicated HTTP requests which can be a bit messy whilst debugging.
For Chrome I find ModHeader + Setting up a profile where the Pragma headers are sent works fine.