Currently I have a problem. Some times when the user loads a page a request gets stuck in IIS (see screenshot). These request are made with AJAX.
For the user everything goes fine, he/she gets all the data and request ends with a 200 status code.
From my understanding the users page request should be stuck since IIS only handles 1 request per session when "EnableSessionState" is set to true, which it is, or am I wrong?
What do status 4096 and 1177224886 mean?
But what i really want to know is:
What is the best way to try and find the source of the problem. I already tried to use the "Failed Requests Tracing" but cant discover anything strange.
Related
I've encountered a weird situation, after registration we're sending an email with a verification link, pretty standard stuff, but somehow clicking on the link seems to make the request twice, looking at the logs, the first time it comes from my IP and the second request comes from some Google IP: 66.102.8.60 (doing a reverse lookup shows google-proxy-66-102-8-60.google.com).
Any idea what's going on and how to prevent this?
The server is running Nginx and the site is Ruby on Rails if that helps.
I do not know the root cause but my best guess is same as Tripleee wrote above - most probably google is scanning urls. This happens in all browsers (well at least in Chrome and Firefox), but only under following circumstances:
the url is clicked from gmail (if you copy paste it to browser tab, the second request is not issued)
the url is clicked for the first time... Subsequent clicks from the same email do not trigger second request
I know it is probably not the answer you expected, but after giving it some thought I figured that operation like this should be handled on server side. In my case I am tracking information about confirmation urls anyways, so the first time the request comes to my backend I am deleting it and proceeding with confirmation normally. Since the confirmation entry is missing in the database for the second request it returns immediately with status 404, 422 or something whatever suits you.
Hope that helps anyone who gets here looking for an answer to this problem ;)
If I make an HTTP request to get index.html on http://www.example.com but that URL has a 302 re-direct in place that points to http://www.foo.com/index.html, what happens if the redirect target (http://www.foo.com/index.html) isn't available? Will the user agent try the original URL (http://www.example.com/index.html) or just return an error?
Background to the question: I manage a legacy site that supports a few existing customers but doesn't allow new signs ups. Pretty much all the pages are redirected (using 302s rather than 301s for some unknown reason...) to a newer site. This includes the sign up page. On one of the pages that isn't redirected there is still a link to the sign up page which itself links through to a third party payment page (i.e. on another domain). Last week our current site went down for a couple of hours and in that period someone successfully signed up through the old site. The only way I can imagine this happened is that if a 302 doesn't find its intended URL some (all?) user agents bypass the redirect and then go to originally requested URL.
By the way, I'm aware there are many better ways to handle the particular situation we're in with the two sites. We're on it! This is just one of those weird situations I want to get to the bottom of.
You should receive a 404 Not Found status code.
Since HTTP is a stateless protocol, there is no real connection between two requests of a user agent. The redirection status codes are just a way for servers to politely tell their clients that the resource they were looking for is somewhere else now. The clients, however, are in no way obliged to actually request the resource from that other URL.
Oh, the signup page is at that URL now? Well then I don't want it anymore... I'll go and look at some kittens instead.
Moreover, even if the client decides to do request the new URL (which it usually does ^^), this can be considered as a completely new communication between server and client. Neither server nor client should remember that there was a previous request which resulted in a redirection status code. Instead, the current request should be treated as if it was the first (and only) request. And what happens when you request a URL that cannot be found? You get a 404 Not Found status code.
I've got a weird bug and wondered if anyone else can think of a cause.
Scenario: -
User tries to access restricted content, gets a turn away page with 403 status code
User logs in
User tries to access content again but should be allowed, browser returns cached turn away page and 403 response (no hit registered on server).
CTRL+F5 or wait a while, browser returns correct content.
This is happening in Firefox and Chrome, I haven't tried Internet Exploder.
I have only reproduced the issue once on my machine whilst on a Skype call with the testers, they can reproduce it every time. They are based over in India though and have a much slower connection to our test site. Could that be a cause?
I saw a related question but that was caused by Squid proxy, i'm not behind a proxy (although testers might be).
I'm loathe to add cache control headers as browsers shouldn't cache a 403 according to the HTTP spec but I need to guarantee with that when a user logs in they get the correct content.
Any thoughts on what might be the cause would be greatly appreciated. In the meantime I'll add some cache control headers to the turn away page just to see if that helps.
I was trying to track down why my site was so painfully slow in IE9 when I pulled out Fiddler and realised that every request is being sent 3 times (twice I get 401.2 and then a success). I verified this happens on all browsers, its just that Chrome's speed was masking this (or it could be that this has nothing to do with my sites performance issues in IE).
I've set up break points in my begin/end request handlers and the request comes in for say a css file. It is not authenticated and the response goes out with a 401.2, I doubled checked that I'm not setting the response status anywhere myself, so somewhere between begin_request and end_request the status is changing to 401.2
Note: I have the runAllManagedModulesForAllRequests=true so I can configure compression, however this setting does not affect this (from what I can see from Fiddler).
I am very ignorant on kerberos/active directory in general but I just cannot fathom that this is a normal handshaking protocol for every single request (perhaps for the first? but not all).
I have scoured the googles and nothing seems to help (adding/removing modules/authentication providers, etc). I mean my site works just fine, its only once you look under the hood that I see the treplicated requests. Note: This also happens when I deploy to production so its not a server specific issue.
Has anyone ever seen this? thanks in advance.
I think this is how NTLM authentication works. The process is discussed here. Note that you will want to set AuthPersistSingleRequest to false to cut down on the number of 401s
When analyzing traffic with a packet sniffer, we are seeing an http response from a weblogic server prior to the completion of the http post to that server.
In this case, the jsp page on the server is basically a static page, no logic to do anything with the contents of the post at this time.
But why would the server send the response prior to completion of the post?
I found Weblogic documentation about how to configure the server to ignore a denial-of-service attack using Http post. Maybe that is what is happening?
No one I know has seen this behaviour before. Maybe some weblogic-savvy person will know what is going on.
Thanks
I don't think that Weblogic is analyzing the JSP to determine whether it is static or not.
My guess is that either
someone else was accessing the server at the same time
you saw the answer to a previous request
[EDIT] To determine what is going on, I suggest to set a breakpoint in the JSP. If you still get an answer without hitting the breakpoint, something further up the stack must be intercepting the request (for example, a cache).