Wen m trying to fire an api through the fiddler, its showing 404. On the other hand, the site is loading properly.
Your sites loads successfully, cause your 2nd request shows a 200 for localhost (and I bet this is a GET request). After the site is loaded, it seems to contain some javascript code that tries to connect to some login site (with POST to aaweb.authorassists.com) and that fails.
Related
We had a little mishap where an https binding was created for a website without a hostname (just an ip), and then another website was created with only an http binding to a hostname using the same ip as the first site.
So the problem is when you navigate to the 2nd site over https, instead of getting an error it just goes to the first website. As a result Google was able to access the first site through the 2nd sites host name over https and now we have lots of duplicate links out in google land.
I've already stopped the bleeding, but now I need to 301 all the bad links that were created by Google for the 2nd site. My plan is that, going forward, anytime a 404 error is encountered in the 2nd site then it will call for just the header from the same link on the 1st site. If the header returns with an OK status then it will do a permanent redirect to the 1st site.
There's just one part of that plan I don't know how to do off the top of my head... what's the best way to intercept the 404s in such a way I can run my code to determine whether it should be 301'd or not?
I'm facing a really weird scenario here with my local IIS. I have hosted multiple sites in the default website in my local IIS. One of them has the login page. From the login page, I'm redirecting the user to another page that is located in another site (which is also hosted in the same IIS inside default website virtual directory).
Now in the submit button click event of my login page, after authenticating the user, I have written a "Response.Redirect(redirect_url)". the redirect_url is being formed dynamically and given as a parameter to the Redirect method.
While debugging, the final redirect_url that is being sent as parameter to Redirect method is:
http://localhost/CP/web/console/console.aspx?sk=3e3cc1a8-73c4-4945-b3f8-08af22ea4324.50008
But after I try to go to the next step, I'm suddenly getting a HTTP 404 error saying that the resource doesn't exist and I have observed that Requested URL shown in the error page is different that what was dynamically sent to the Response.Redirect(...) method.
In the error page, the requested url shows the value as
http://localhost/CP/web/console/localhost/CPLogin?err=5
whereas my actual requested url formed in the code is:
http://localhost/CP/web/console/console.aspx?sk=3e3cc1a8-73c4-4945-b3f8-08af22ea4324.50008
I'm just unable to understand why the requested url is getting changed automatically.! Also, I observe that "localhost" is being appended to the requested URL again which is not what is supposed to happen.
Please visit THIS link[^] to understand this question more clearly. I have added screen shot of the error page.
http://amoghnatu.wordpress.com/2013/09/16/question-please-help-iis-throwing-http-404-not-found-but-requested-resource-actually-exists-requested-url-also-changing-automatically/[^]
Thanks a lot.!
Indeed, the problem was with the way I had hosted the sites in my application. I just removed all the sites related to my application from IIS and then hosted all of them again much more carefully. This resolved the "wrong redirect url" problem.
Also, I had some tables with missing required data because of which I was getting the error code.
So after I got all the tables filled with the required data and also after properly hosting the application in IIS, my problem got resolved.
In IIS, go to relevant folder, right click and "browse". Check out what is the URL. In most cases, this is due to the URL should have port number appended. For instance it will be something like :
http://localhost:<port number>/CP/web/console/console.aspx?sk=3e3cc1a8-73c4-4945-b3f8-08af22ea4324.50008
instead of
http://localhost/CP/web/console/console.aspx?sk=3e3cc1a8-73c4-4945-b3f8-08af22ea4324.50008
I've come across something that's puzzled me for the past 3 hours regarding Facebook's login procedure.
I visited http://m.facebook.com (with UA Spoofer installed and set to Nokia Lumia User-Agent) and proceeded to log-in whilst monitoring the headers. I purposely entered the wrong password for an account I have.
When pressing log-in it sends a POST request to this URL: https://m.facebook.com/login.php?refsrc=http%3A%2F%2Fwww.facebook.com%2F&refid=8 the status code returns a 200 response code.
Then instantly afterwards it does a GET request to this URL: http://m.facebook.com/login.php?refsrc=http%3A%2F%2Fwww.facebook.com%2F&refid=8&e=1348022&email=frankthebutcher%40hotmail.com&signup_layout=layout%7Cbottom_clean%7C%7Cwider_form%7C%7Cprmnt_btn%7Cspecial%7C%7Cst%7Ccreate%7C%7Cheader_button%7C%7Chdbtn_color%7Cgreen%7C%7CFeb1&li=jFMuUdDWbmFhq8b-zAjEOHnE&_rdr
Which is the URL that says the password was incorrect.
But, where is that redirect coming from? There is nothing in the response headers from the first POST request, and JavaScript isn't enabled.
Try it on Chrome. Would love to know how it's doing that so I can adjust the mobile app I'm developing accordingly.
Solved: In my mobile app I was sending the POST request to the right URL, but the URL string I used was encoded which was causing the problem.
The first POST request is sending back a Location header which tells the browser to step-ahead from this request and proceed with the next. The second request is just the browser then using that new Location supplied and moving forward.
here's what you see from the first POST response:
However, from what I can see it's a 302 (redirection: found) response, not a 200 OK. Something tells me that you're judging the response headers on the final request, not the intermediate redirect/handoff.
I have got a problem that I am redirecting the page to other domain using response.redirect, It works well in Firefox, but in ie it shows the blank web page. when i tried to see what happens in fiddler, it says that object Moved, but the redirect doesn't happens here. Interesting thing is I couldn't replicate this in my local environment, but it happens in my DEV and QAL servers.
When i tried in dev & QAL servers, IE redirects it to the desired page.Can anyone help??
Try to clear cache in Internet Explorer
You probably set redirect to some page and then change it to other page.
Sometimes when permanent redirect occurs, IE cache it and don't ask for a page one more time but get the redirect path from cache. IE don't even refresh the address textbox which is misleading.
I have a Silverlight (v3) application that uses WebRequest to make an HTTP POST request to a webpage on the same website as the Silverlight app. This HTTP request gets back a 302 (a redirect) to another page on the same website, which HttpWebRequest is automatically supposed to follow (according to the documentation).
There's nothing particularly special about the code that makes the request (it uses the browser's HTTP stack, it is not configured to use the alternate inbuilt Silverlight HTTP stack):
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Format("{0}?name={1}&size={2}", _UploadUrl, Uri.EscapeUriString(Name), TotalBytes));
request.Method = "POST";
All this works fine in Firefox and Chrome; Silverlight makes the POST HTTP request, receives a 302 response and automatically does a GET HTTP request of the specified redirect URL and returns that to me (I know this because I used Fiddler to watch the HTTP requests going on).
However, in Internet Explorer (v8), Silverlight does the POST HTTP request and then throws a WebException with a 404 error code!
Using Fiddler, I can see that Silverlight/Internet Explorer was successfully returned the 302 status code for the request, and I assume that the 404 status code (and associated WebException) that I get in Silverlight is because as far as I know HTTP requests that are done via the browser stack can only return 200 or 404 due to limitations. The real question is why does Internet Explorer not follow through the redirect like the other browsers?
Thanks in advance for any help!
EDIT: I would prefer not to use the Silverlight client HTTP stack because to my knowledge requests issued by it do not include cookies that are a part of the browser's session, critically including the ASP.NET authentication cookie that I need to be attached to the HTTP requests being made by the Silverlight control.
EDIT 2: I have discovered that Internet Explorer only exhibits this behaviour when you do a POST request. A GET request redirects successfully. This seems like pretty bad behaviour considering how many websites now do things in the Post-Redirect-Get style.
IE is closer to the specification, in that in responding to a 302 for a POST the user agent should send a POST (though it should not do so without user confirmation).
On the other hand, FF and Chrome are deliberately wrong, in copying ways in which user agents were frequently wrong some considerable time ago (the problem started in the early days of HTTP).
For this reason, 307 was introduced in HTTP/1.1 to be clearer that the same HTTP method should be used (i.e. in this case, it should be a POST) while 303 has always meant that one should use GET.
Therefore, instead of doing Response.Redirect which results in a 302 - that different user agents will handle in different ways, send a 303. The following code does so (and includes a valid entity body just to be within the letter of the spec). There is an overload so you can call it with either a Uri or a string:
private void SeeOther(Uri uri)
{
if(!uri.IsAbsoluteUri)
uri = new Uri(Request.Url, uri);
Response.StatusCode = 303;
Response.AddHeader("Location", uri.AbsoluteUri);
Response.ContentType = "text/uri-list";
Response.Write(uri.AbsoluteUri);
Context.ApplicationInstance.CompleteRequest();
}
private void SeeOther(string relUri)
{
SeeOther(new Uri(Request.Url, relUri));
}
I believe this was a feature change in Internet Explorer 7, where by they changed the expected 200 response to a 302 telling IE to be redirected. There is no smooth solution to this problem that I know off. A similar question was posed a while back here.
Change in behavior with Internet Explorer 7 and later in regard to CONNECT requests