I encountered a web form today which works for Firefox but not chromium (tested Edge and Chrome).
The form action leads to a HTTP 302, after that another 302, and then finally 200 - at least with Firefox and Fiddler and Rested (brower addon). However, when trying with chromium it's just plain 404 Not found. I double checked all headers and parameters, it's the same for both.
I tried to document what I saw.
https://i.stack.imgur.com/Ux6B1.jpg - working in Rested
https://i.stack.imgur.com/YoBnv.jpg - whatever chromium is doing
Do I have to call the people responsible for the form or is there any browser setting I am not aware of?
Related
In Chrome I like to look at the result headers and see relevant debugging http requests. Chrome doesn't let you see that if the result was a 400 or 500 error because instead it redirects you to a "This page isn’t working" page that they have baked in.
Is there anything in Chrome that allows us to disable this behavior so we can see the actual result with it's headers?
I am trying to make a CORS request with credentials(Cookies attached) and Chrome is not attaching the Cookie to my request. I have set the cookie to a sub-domain of the existing page and i could observe it is set successfully from the Cookie manager.
I do not have this problem with Chrome 78th version(latest version). But for the previous versions, I have this problem(I have checked 75 and 77). As well as i do not have any problem with other major browsers also. They also attach cookies without a problem.(I have tested my code with Firefox, IE, Opera and Edge)
This how I have set the Cookie from external service end.
res.setHeader('Set-Cookie','cdn-token=exp3header_same-site-none; domain=.local.com; path=/; SameSite=None;');
Complete sample code base can be found in following links:
External service - https://github.com/bhanukayapa/cors-backend.git
Front-end application - https://github.com/bhanukayapa/cors-angular-frontend.git
Can someone please explain the root cause for this problem? I checked Chrome release notes also. I could not find and bug fix or improvement related to this. Thanks in advance.
If setting SameSite=None this must be paired with Secure. e.g.
res.setHeader('Set-Cookie','cdn-token=exp3header_same-site-none; domain=.local.com; path=/; SameSite=None; Secure');
I'm using Chrome Version 31.0.1650.63 m.
Recently, I've noticed a few errors being thrown in the Chrome developer console, but nothing seems wrong with my site. Upon investigation, they seem to be related to an embedded youtube link. The markup in question is as follows:
<iframe width="560" height="315" src="http://www.youtube.com/embed/hhhrWFxWQRk" frameborder="0" allowfullscreen></iframe>
The video itself is irrelevant (I just grabbed the first one I saw on youtubes front page as a test), but I've included the link I'm using here in case something very specific is happening.
The response headers from the request made in Chrome are as follows:
Alternate-Protocol:80:quic
Cache-Control:no-cache
Content-Encoding:gzip
Content-Length:2560
Content-Type:text/html; charset=utf-8
Date:Sun, 12 Jan 2014 20:35:54 GMT
Expires:Tue, 27 Apr 1971 19:44:06 EST
Server:gwiseguy/2.0
X-Content-Type-Options:nosniff
X-Frame-Options:ALLOWALL
X-XSS-Protection:1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube
And the errors I'm getting in the Chrome developer console are as follows:
Invalid 'X-Frame-Options' header encountered when loading 'http://www.youtube.com/embed/hhhrWFxWQRk': 'sil' is not a recognized directive. The header will be ignored.
Error parsing header X-XSS-Protection: sil: expected 0 or 1 at character position 0. The default protections will be applied.
In big red letters. The first thing I notice is that the errors both reference the value "sil", which I don't see in any of the response headers for HTTP request.
The video displays and plays fine, and the errors say that default settings will be used - so this doesn't look like an issue. However, I'm keen to understand what's going on, and why these errors are occurring.
I notice that the errors relate to XSS, and from my research, I think the X-XSS-Protection header is for IE8 only, and the value being returned from YouTube is invalid (report= et al). The X-Frame-Options header's value seems to be invalid according to the specification, but Wikipedia (I know!) references the ALLOWALL option:
In addition to that, some advertising sites return a non-standard
ALLOWALL value with the intention to allow framing their content on
any page (equivalent of not setting X-Frame-Options at all).[31]
Is this a valid concern? Is this a Chrome parsing error, an issue with youtube's headers, or am I completely missing the point?
I have also done some testing in Firefox v26, IE 11.0.6600.16476, and Opera 12.16, and none of those browsers produce this error.
Looks like this was an issue with that particular version of Chrome - now Chrome has updated to v32, I no longer get this issue. I am, however, getting a load more warnings and errors related to linking to YouTube.
We use doubleclick from Google to track user information with a floodlight tag in an IFrame, but recently the response is causing an error in the Chrome dev tools:
Invalid 'X-Frame-Options' header encountered when loading 'http://123.fls.doubleclick.net/activityi;src=123;type=123;cat=123;ord=123': 'ALLOWALL' is not a recognized directive. The header will be ignored.
Here is a blog post on the matter: http://ipsec.pl/node/1094
It looks like ALLOWALL has recently been added to allow any site to use the code as a src (similar to not including that option at all) and doubleclick is including this option in their response. Out of IE, Firefox and Chrome, Chrome is the only browser that throws the error. Does that mean that Google is using an option in doubleclick that doesn't work in their own browser? It's hard to imagine a Google team not testing in Chrome.
It seems to me that if the header is being ignored, and the header has the same effect as not including any cross site restrictions with X-Frame-Options, the error will not affect anything. Also, since the error occurs on the response, the tracking that is done with the original request should be fine, right?
The issue was filed as a bug report: Bug 110857 - X-Frame-Options should accept ALLOWALL as a valid value and
has been addressed and the fix is in the main branch of WebKit, once the latest WebKit engine is in use by Chrome, the messages will disappear.
for more information see: Webkit Changeset 144105
This example to load a url in an iframe works. However when I change url to something like http://www.yahoo.com the iframe doesn't load antyhing
Here is an example side by side.
In Network tab of developer tools for Chrome, I see that request to Yahoo was cancelled. In FF it doesn't give any errors, just doesn't return any content. IE9 gives a message that It cannot display this content.
This happens in Chrome, FF and IE9 (I haven't tested previous versions of IE).
That is because Yahoo itself prevents this from happening.
It has been noted here: https://stackoverflow.com/a/9013722/476786
To see for yourself, try setting the source to http://www.google.com/ which won't work as well, but then try http://www.bbc.co.uk/ and that will work.
Possibly works as described here: https://stackoverflow.com/a/2896705/476786 using X-FRAME-OPTIONS
If the site hosting the webpage forces the use of a secure HTTPS connection, some browsers (chrome for sure) will require that all network resources use HTTPS as well.
Basically if your site forces HTTPS, try setting src="https://yahoo.com"
This won't solve OP's answer directly due to it being a limitation of Yahoo itself, but other people viewing this page might be experiencing this issue as a result of this (I was).