For example, day, in a somewhat REST-oriented environment, a request comes in for an object that doesn't exist, like:
GET http://example.com/thing/5
Is there anything wrong with sending back a 404 response who's body is the same as a a different page? For example, responding like:
404 body: [content from "http://example.com/thing/" which is a list of things]
Does it make any sense to do this? Will this cause any problems with certain browsers? Is it confusing to the user? Or is this perfectly fine to do?
Along these same lines, I would have the content of the 404 response match the request's accept headers as best I could. (ie. abide by content negotiation with the user agent)
For example, a xml or json request would get something along the lines of a simple error message and something that says "look here for similar things", while an html request would get an HTML page that has the error message as well as the content of the list page (as I indicated above)
I think it depends on how the Restful web services are being consumed. If I'm programmatically consuming the web service from a different application, then I would want the status code together and a plain text message instead of a message decorated with HTML tags. I mean, say for example, it doesn't make sense to return a bloated 404 content if your user makes the web service call using Curl because the message will not be readable to them.
You could have different "consumes" for each restful webservice. If it's an XML request, then you return 404 and a plain text message. Otherwise, you return the error page content.
I don't see anything wrong with it. In our webservice we always send back a json error object which includes stacktraces and other details about the response. Even on a regular web server, you get at least text which can be displayed in a browser saying that you got a 404 response.
Related
Consider the following situation:
I have a MVC setup where the view invokes a mapper to get a specific URL for a href attribute. The mapper holds keys to make the referencing easy.
Now the view requests an invalid key, so the mapper responds with say /invalid_url. But the dispatcher knows this URL and when a user clicks the link an error message will be displayed about how bad we feel.
But what if the Google Bot visits this invalid URL?
What would a search engine friendly status code be? I feel like 500 would be appropriate because it is a server side failure. But then this has the feeling of being a temporary error or somehow not related to the URL but to the internal mechanics. The other option that comes to mind is 404. This is also valid because the requested page does not exist. However 4xx errors are client side errors ("You requested the wrong URL. So it's basically your error"). And it just doesn't feel like a client side error to me.
Am I overthinking things? Should I just go with 404?
When I have a question like this, I refer to a site like http://www.restapitutorial.com/httpstatuscodes.html
5xx error codes imply that the server made a mistake. But you're saying the view (client-side) requested the wrong key. That sounds like a client-side error to me. While it's not the user's fault, the server doesn't know this, and the requested URL really doesn't exist. So a 404 would be appropriate.
But this is a weird case, and you should still want to fix the underlying issue of the client consistently(?) requesting a bad url.
I'm trying to manipulate a .net ASP form on a site that's using AJAX Control Toolkit. The site is only accessible to valid logins, and I do have a valid account. It consists of a search page with a form. Each time a submit button is clicked on the form, the server is updated using the values of some text fields on the form, and then the VIEWSTATE and EVENTVALIDATION tokens will be updated based on the response from the server, ready for the next request.
I'm using HttpClient in Java to do this. I suspect there's something I'm not doing correctly with regard to interacting with ASPX forms in general.
When I hit the main search page for the first time (cookies are validating my login with the server), I get the HTML for the search page back. I extract the VIEWSTATE and EVENTVALIDATION tokens for the next request. I've examined the exact form fields and their values that need to be sent to the server in a POST by looking at the Chrome debugger utility after making a request on the site manually. I've replicated them exactly as they should be, inserting the VIEWSTATE and EVENTVALIDATION appropriately.
But the response I get back from the server is not what it should be. What I get back is just the same HTML for the main search page that I get the first time I hit the webpage. The form data I'm using looks like this:
ctl00$ScriptManager1:ctl00$ContentPlaceHolder1$UpdatePanel1|ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$acceptButton
ctl00_ContentPlaceHolder1_TabContainer1_ClientState:{"ActiveTabIndex":0,"TabState":[true,true]}
__EVENTTARGET:
__EVENTARGUMENT:
__LASTFOCUS:
__VIEWSTATE:<token extracted from first page hit>
__VIEWSTATEENCRYPTED:
__EVENTVALIDATION:<token extracted from first page hit>
ctl00$ContentPlaceHolder1$LabelFee:0
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$RadioButtonList1:Person
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$snameText:aSurname
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$HiddenField1:
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$fnameText:aFirstname
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$dayFromTextBox:01
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$monthFromTextBox:January
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$yearFromTextBox:2001
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$dayToTextBox:01
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$monthToTextBox:January
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$yearToTextBox:2008
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$DropDownList1:aCity
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$PropText:
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel2$RefText:
__ASYNCPOST:true
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$acceptButton:Accept
I've also tried replicating the headers that the Chrome debugger shows, so my request is including the same Content-Type, Host, Origin, Referer, User-Agent (for my browser) and every other header, including this header X-MicrosoftAjax: Delta=true.
I know there's a lot of moving parts here, but I intentionally haven't mentioned how I'm actually making the POST request with the HttpClient lib because I'd don't want to complicate the question anymore or alienate anyone who doesn't know Java but knows ASP. I'd like to know if there's an ASP issue I'm not addressing, but I can post the Java code is necessary.
Edit:
I've checked the debugging info that HttpClient is outputting just before sending the request, and the form data is being added properly as multi-part form data. The headers are all there too.
This answer is a long shot, but I've seen weirder things.
You mention this header:
X-MicrosoftAjax: Delta=true
I did some deep googling and found that this is often shown as all lower case in dumps of Ajax and UpdatePanel POST requests:
x-microsoftajax: Delta=true
See here and here.
Could it be as simple as not casing the header correctly?
I eventually got this working. The problem was not specific to ASP in general, it was actually a problem with how Java (specifically HttpClient) was sending the request. I was using HttpClient to compile the request using multi-part form, but after using Fiddler to analyse and compare the requests (see the edited part of this question for more details on that) sent from both my application and the actual webpage, my app request was structured very differently.
The real website request had the form options embedded in the request body in what looked like a URL encoded query string. My request was a series of entries in the request body where each option was wrapped in the Content-Type and Content-Disposition headers. The requests succeeded after changing the POST to add the parameters like:
request.setEntity(new UrlEncodedFormEntity(paramList));
Whats difference between return new HttpStatusCodeResult(500) and cause a real error in the action (like division by zero)?
I'm asking because my customErrors works fine when a error like division by zero ocurred, but if i return new HttpStatusCodeResult(500) the customError dont show my page
HttpStatusCodeResult is for notifying the browser of the result of an action, using an actual HTTP status code. For example, if the browser tries to load an image that is no longer available, you could send a 404. If the user is attempting to access a resource that requires authentication, you could return a 401.
Errors caused by your code often don't need to inform the browser of an error, but instead need to inform the user, using an error page with a message. This error page though, would (most likely) be sent to the browser with an HTTP status code of 200.
tldr; these are two different types of errors with different meanings, meant for different recipients.
I'm a bit confused or maybe I don't fully understand http requests.
There is a website on which the search results are fetched through a GET request. I can see the whole parameter list in Firebug and if I click "search" the results are displayed as you would expect. What I don't understand is if I take this request URL (with the same parameters) and copy it in a new browser tab it doesn't return results anymore. Instead I see a 500 - Internal server error.
Can someone explain why is this happening or what can I do to see the results when accessing the URL?
As robert_b_clark suggested the solution is to send the referrer header when making the request.
I'm a noob when it comes to ASP.NET. I know few basic commands such as Response.Redirect("URL") to redirect my application web page to a different location.
However i receive HTTP Error 400 - Bad Request, whenever i try to use the code shown below
Response.Redirect(Server.UrlEncode(this.Downloadlink));
where this.Downloadlink is a user defined property which returns something like this
http://mdn.vatsag.net/fp;files/DOWNLOAD/VTSetup.exe
If i post this link in the browser, the .exe file pops up (means the link is good)
However this error comes when i use the ASP.NET code.
Any form of response on this issue/reason is deeply appreciated.
See here: http://www.kirit.com/Response.Redirect%20and%20encoded%20URIs
In short: if you quickly want to fix the issue, remove the part of your code that is UrlEncoding the URL!