I have deployed my asp.net MVC app to production, and it works as expected. However, when using F12 in IE to see the Network requests that are being made to the server, I see the requests being sent with this format:
http://172.16.10.2/VMSWebTest/(F(pZPg-rE4Nghw1pU6TbKBwuNIeLCVHnerv1BO7BG3hZlmLxqretATeKFdrZU2b9Qr_rg2-wieUwZOJ9PkcwWdRzRSP_oUEI5mdmd4vzbrqbM1))/Tiers
instead of this format:
http://172.16.10.2/VMSWebTest/Tiers
Where is that (F(pZPg-rE4Nghw1pU6TbKBwuNIeLCVHnerv1BO7BG3hZlmLxqretATeKFdrZU2b9Qr_rg2-wieUwZOJ9PkcwWdRzRSP_oUEI5mdmd4vzbrqbM1)) part of the URL coming from? Why? What is it's purpose?
I've noticed this only seems to be with IE, as the request url are as expected when using Chrome.
It might be that you are the victim of a bug where ASP.NET can not recognize IE10, please see the suggestions in this answer:
IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Specifically, there is a hotfix available: http://support.microsoft.com/kb/2600088
Related
I want to simulate a fake 404 status code from the backend to see how my website will behave.
I don't want to mock fake response status in the code I would like to use some tools.
Cause sometimes I want to test it on the production which has version x and I don't want to waste time downloading this code and checking if there it is working.
Just simply mock response header status code for some test value like 404 for the fast check.
I tried to use software like Requestly - chrome extension.
And configured it like :
Modify response for header status put value 404 for google.com site.
But when I open google.com site I got status 200:
Do you know how can I change the status code of the given request?
Maybe by using different soft?
Status is not an HTTP response header. Status Code is an HTTP response code and Chrome does not allow to modify the response code of a request. There are two possible ways to solve this using Requestly
1-Step solution using Requestly Desktop App (Reliable & Guaranteed to work)
You can use any MITM proxy to intercept the request and simulate the status code. However, given my experience with Requestly, I'd explain how you can do it with Requestly Desktop App
Install Requestly Desktop App,
Go to Rules Tab and Click on New Rule
Select Modify Response
Define the exact URL (or Pattern) and define the status code. That's it.
Screenshot
Demo
https://www.youtube.com/watch?v=nLcIZGmMAtQ&ab_channel=Requestly
Using Requestly Browser Extension (2-Step Process, Should Work in most sites but there could be some CORS Issues)
Install Requestly
Use Requestly Mock Server and create a new mock which serves 400 or 404
Use Requestly to set up a Redirect Rule which redirects your original request to the URL of your mock request
Here are a couple of examples using the extension
Simulate 500 in Twitter Create Tweet API
Simulate 404 in BlinkIt Search API
Footer Notes
Desktop App-based solution is more reliable and guaranteed to work while Extension-based solution has technical limitations and there may be some CORS Issues depending upon your backend So prefer to use Solution 1.
PS - I built Requestly (& still building it with lots of heart)
In DevTools on the Network panel, right click a resource and select Block Request URL or Block Request Domain.
Does that help in your use case?
Try using ModResponse: https://chrome.google.com/webstore/detail/modresponse/bbjcdpjihbfmkgikdkplcalfebgcjjpm. You can add "Replay response" on the URL that you want to replay, visit that URL, then open up ModResponse again to edit the HTTP status code. You can also use it to edit the HTTP response body and header as well.
Chrome has a long history of ignoring Set-Cookie header. Some of these reasons have been termed bugs and fixed, others are persistent. None of them are easy to find in documentation.
Set-Cookie not allowed in 302 redirects
Set-Cookie not allowed if host is localhost
Set-Cookie not allowed if Expires is out of acceptable range
I am currently struggling with getting chrome to accept a simple session cookie. Firefox and Safari seem to accept most any RFC compliant string for Set-Cookie. Chrome stubbornly refuses to acknowledge that a Set-Cookie directive was even sent on the request (does not show up in Developer Tools (Network)). curl looks fine.
So does anyone have either 1) modern best practices for cross-browser Set-Cookie formatting or 2) more information regarding what can cause Chrome to bork here?
Thanks.
One thing that has bitten me and is not on your list: if you are trying to set a secure cookie through HTTP on localhost, Chrome will reject it because you are not using HTTPS.
This kind of makes sense, but is annoying for local development. (Firefox apparently makes an exception for this case and allow to set secure cookies over HTTP on localhost).
I use Asp.net web from and IIS 8 and sometimes I saw this result instead of Html result in my browser:
I use "FortiWeb" as Web Application Firewall(WAF) and it configured to convert request http to https.
This error sometimes occurs in random page.
Am I mistaken in IIS setup?
For me it seems to me a normal Http 200 OK message.
It states "Content Encoding gzip" also.
Isn't it just a compressed version of the normal HTTP resonse? Which can happen if comression is enabled in your IIS configuration.
I'm trying to do requests to my REST API, I have no problems with Firefox, but in Chrome I can't get the browser to work, always throws 200 OK, because no if-none-match (or similar) header is sent to the server.
With Firefox I get 304 perfectly.
I think I miss something, I tried with Cache-Control: max-age=10 to test but nothing.
One reason Chrome may not send If-None-Match is when the response includes an "HTTP/1.0" instead of an "HTTP/1.1" status line. Some servers, such as Django's development server, send an older header (probably because they do not support keep-alive) and when they do so, ETags don't work in Chrome.
In the "Response Headers" section, click "view source" instead of the parsed version. The first line will probably read something like HTTP/1.1 200 OK — if it says HTTP/1.0 200 OK Chrome seems to ignore any ETag header and won't use it the next load of this resource.
There may be other reasons too (e.g. make sure your ETag header value is sent inside quotes), but in my case I eliminated all other variables and this is the one that mattered.
UPDATE: looking at your screenshots, it seems this is exactly the case (HTTP/1.0 server from Python) for you too!
Assuming you are using Django, put the following hack in your local settings file, otherwise you'll have to add an actual HTTP/1.1 proxy in between you and the ./manage.py runserver daemon. This workaround monkey patches the key WSGI class used internally by Django to make it send a more useful status line:
# HACK: without HTTP/1.1, Chrome ignores certain cache headers during development!
# see https://stackoverflow.com/a/28033770/179583 for a bit more discussion.
from wsgiref import simple_server
simple_server.ServerHandler.http_version = "1.1"
Also check that caching is not disabled in the browser, as is often done when developing a web site so you always see the latest content.
I had a similar problem in Chrome, I was using http://localhost:9000 for development (which didn't use If-None-Match).
By switching to http://127.0.0.1:9000 Chrome1 automatically started sending the If-None-Match header in requests again.
Additionally - ensure Devtools > Network > Disable Cache [ ] is unchecked.
1 I can't find anywhere this is documented - I'm assuming Chrome was responsible for this logic.
Chrome is not sending the appropriate headers (If-Modified-Since and If-None-Match) because the cache control is not set, forcing the default (which is what you're experiencing). Read more about the cache options here: https://developer.mozilla.org/en-US/docs/Web/API/Request/cache.
You can get the wished behaviour on the server by setting the Cache-Control: no-cache header; or on the browser/client through the Request.cache = 'no-cache' option.
Chrome was not sending 'If-None-Match' header for me either. I didn't have any cache-control headers. I closed the browser, opened it again and it started sending 'If-None-Match' header as expected. So restarting your browser is one more option to check if you have this kind of problem.
We have a simple HTML login form on our embedded device's web server. The web server is custom coded because of severe memory limitations. Regardless of these limitations, we like Chrome and would like to support it.
All browsers post an HTTP Request to our login form containing the expected "username=myname&password=mypass" string, but not Chrome. Instead we receive from Chrome a "Content-encoding gzip deflate" request. BTW, by "all browsers", I mean this was tested to work fine on Internet Explorer versions 9 beta, 8, 7, 6 ; Firefox versions 4 beta, 3, 2 ; Opera 10, 9 ; Safari 5, 4, 3 ; and SeaMonkey 2.
Referring to section "14.2 Accept Charset" of the w3.org's http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html we tried sending back a HTTP 406 code to indicate that this server does not support that encoding in the hope that Chrome would try again and post the expected strings the standard way. The 406 code returned by the web server is clearly displayed in Chrome's "Inspect Element" window, but it seems to be treated by Chrome as an error code, and no further requests are sent to the web server. "Login failed." We also tried HTTP return codes 405 and 200, same result.
Is there a way to get around this behavior either with client-side JavaScript that will prevent Chrome from sending the "Content-encoding gzip deflate" request, or with a server-side response that will explain nicely to Chrome we don't do gzip, just send it to us the regular way?
We tried posting to the Google Chrome Troubleshooting forum with no response.
Any help would be greatly appreciated!
Best regards,
Bert
You're looking in the wrong section for the error code: Section 14.11 of RFC 2616 specifies that you send a 415 (Unsupported Media Type) if you can't deal with the Content-Encoding.
It sounds like when using chrome to do a post to a server the first time, chrome defaults to using a gzip encoding. Pretty strange.
Easy way out is to just place your username/pass as GET parameters, and when sending the response, as long as you don't send gzip content encoding, chrome should start using none-gzipped posts from that point on. Hope that works?
I tested this out a bit with a simple Python script that printed to stdout. I thought I was getting the same problem, but then I realized that I was just forgetting to flush stdout. It seems that Chrome always sends the request up to the end of the headers before sending the request content, and you have to use a second recv call to get the POST data. In contrast, the entire Firefox request is returned in a single recv call.