I try to Login at a website with a HTTP POST. It doesn´t work, I get the status Code 200 instead of 303. Which mistakes could be the reason for that?
The typical explanation is that the website is designed to respond with the login page, if the authentication failed. A 200 can indicate that page content is available and returned successfully, while the page content indicates that the login failed. The most likely reason for this is browser compatibility, whereby some non-standard browsers might react differently to non-200 responses.
Related
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.
Why would a site respond with an HTTP 302 (redirect) and include HTML in the payload. Check out godaddy.com. You will need an account to log in. When you log in you will see in an HTTP trace (I use firebug), a 302 returned with the location: header as expected, however the payload includes the complete HTML page. Next, as expected, you see the URL from the location header fetched with the same HTML payload. Why would they do that?
I don't know anythign about GoDaddy but it may be a way to somewhat post information back to their server but not force your browser to do an "auto form post". I'm working with ADFS currently and with that security (and many others) the authentication authority sends back a 200 with html of a form, which when loaded immediately posts that form to your server.
I'm currently experimenting with sending back a 302 with the payload that redirects back to the server instead. This prevents a flash of white as that auto-post is taking place.
It's just a guess :)
i have two web site: one HTTP site and other is HTTPS site. I will validate the credentials in HTTPS environment and will return to HTTP once authorized. The same is working fine in IE but in Mozilla im getting a warning as shown below.
How to avoid this warning message? currently im posting from HTTPS aspx page using java script to the HTTP page.
I think the problem is that you are posting from https to http. If you instead did a GET and preferably a GET without parameters you might get around the problem.
I agree with leppie. There is nothing is wrong with your code. It is how a good browser should work. Submitting sensitive data from a secure site to an unsecure site should not go without warning.
Recommended solution
Make both pages/sites "submitting page/site" and "submitted page/site" to run over HTTPS.
You can disable that warning message in Firefox which is not recommended. Go to FireFox>Option>Security>Warning Messages>Settings.
I want to redirect users, after HTTPS login, to the HTTP pages on the site. Using HTTPS for the whole site is not going to happen.
What I have so far is the following:
User posts the login form to the secure site
The secure server validates the credentials
The secure server sends a 302 redirect to the client
This works, except on my machine in IE6 the user gets an error message because the default is to warn when exiting a secure page. These errors are a usability killer for me and thus a showstopper. I changed it so that step 3 is
Server sends html code with a meta refresh
But this is very slow; even on my local machine it's noticeably slower than doing the 302 redirect.
Is there a better way to accomplish the goal of a hassle-free redirection on standard settings that people use? IE6 represents 20%-25% of our traffic. Also, does anyone have any good info about which browsers will warn and which won't warn for the 302 redirect? I am considering black-listing IE6 so that only it gets the slow meta refresh and everyone else gets the fast 302.
Reviving an old topic , but to make it compelete posting the following so other devs can have a choice of implementation
One way of moving bettween https to http without a warning message is to use client redirect using javascript.
Steps
User enters login details on a https form and click on login button
login button will post back to https form for login validation ( assuming login is correct) will redirect to a holding page which is also under https and displays the message ( please wait while the site redirects you)
This holding page does a javascript redirect to the http page
no browser warning message will be displayed
HTH
I am considering black-listing IE6 so that only it gets the slow meta refresh and everyone else gets the fast 302.
I would do something like that. Also include a plain HTML link in the body for accessibility.
Note that some other browsers do give a similar warning about leaving an HTTPS site, but in their case it is accompanied by a (generally pre-ticked) “don't ask me again” button. So by the time they get to your site they will almost certainly have told that warning to disappear. This doesn't make the warning less pointless, but at least it alleviates the problem.
The secure server sends a 302 redirect to the client
You shouldn't 302 in response to POST. A theoretical browser that took the HTTP RFC seriously might respond to that by re-POSTing the form to the new URL. (Which, ironically, would make IE6's warning about information “being retransmitted to a nonsecure site” less misleading.) Instead use “303 See other”.
I don't think there's any other way. That error message is for the user's benefit, and is present in IE 7 and Firefox 3 now as well. The only way that I know of to prevent it is to add your site as trusted within the browser.
Update: Oh, so it's not the mixed content error. I know which one you mean, though I still don't think you can disable the error. Generally, security errors are for the users benefit to protect them from potentially dangerous sites, and as such, cannot be disable by the (potentially unsafe) website itself.
I am building a simple HTTP server for a project.
Most websites have custom 404 error pages. Sometimes though, you'll see Firefox spitting a generic 404 page (or 405, etc...).
How does it decide what to do?
What should the HTTP response be?
Is "HTTP/1.0 404 NOT FOUND" enough?
Thanks
If server can't find the requested resource (e.g. a webpage), it sends an HTTP/1.0 404 NOT FOUND in the HTTP header section.
Servers can map an error page for this error, so you can get a readable error page. Browsers can also map an own error page, so you can see a browser-specific error 404 message.
You can see the error code in the status field in log files.
You can redirect your user to a specific page with this structure:
<HTML>
<head>
<meta HTTP-EQUIV="Refresh" CONTENT="5; URL=not404.htm">
</head>
</HTML>
See details on Welcome to 404 Error Pages .com
It is perfectly valid to return an html body with a 404 response code. If no body is provided then the browser will show a default page.
If you only send HTTP/1.0 404 NOT FOUND then the browser default will be displayed.
If you add a body to the response the browser will mostly use that.
If you are creating an HTTP server you might want to look at the RFC that describes the protocol: http://www.faqs.org/rfcs/rfc2616.html
For the 404 status code it says:
The server has not found anything
matching the Request-URI. No
indication is given of whether the
condition is temporary or
permanent. The 410 (Gone) status code
SHOULD be used if the server knows,
through some internally configurable
mechanism, that an old resource is
permanently unavailable and has no
forwarding address. This status
code is commonly used when the server
does not wish to reveal exactly why
the request has been refused, or when
no other response is applicable.
You can't control how the browser will treat each status code, you shuld rely on its good behaviour.
That said, you may benefit from using one of the existing HTTP servers. Look at this question on how to create an HTTP server in C or C++ posted few days ago,
So, Firefox won't show a generic 404 error page under most circumstances; you're thinking of Internet Explorer, which ignores a website's 404 page if it's below a certain size and displays its own.
Usually it set up in the webserver, ie: When the server gets a 404, refer it to this page.