So I am using http://apikitchen.com/ to debug an issue I am having with a drupal service.
I use: http://vmstage.dop.com/mobile/user/login.json as the URL to test. Method is POST and add two parameters:
username
password
Set the username and password as whatever you like. It will return 401 Unauthorized: Wrong username or password. which is what you should get since you don't know the username or password
I saw they had a mac osx version of this and when I run the exact same thing in their desktop program I get a 406 - Not acceptable.
The reason I am testing in this is because an iPhone app I am working relies on the drupal services to login and I am getting the same thing running through the iPhone emulator.
Back to the API kitchen thing, it works through the browser, but not through their desktop program..makes me think it has something to do with content-type or port. What do you guys think?
I am the author of APIKitchen. I don't think there are any differences between the web and desktop version but if you can provide a sample url with parameters I can quickly look into it.
Generally a 406 error is used to indicate that a request is malformed in some manner. I am not familiar with the tools you are using, but I think you are on the right track in looking for things that might be different between the different requests. You should look at the header differences (including content type). Also, maybe there are some JSON encoding differences between the two different platforms that the API doesn't like.
Related
I have noticed that many http clients including Firefox and Chrome don't allow file downloads for http response codes with 4XX and 5XX. However, some clients allow these downloads, like curl and wget (with --content-on-error option).
Both Chrome and Firefox don't provide nice exception messages.
Chrome fails with ERR_INVALID_RESPONSE. Firefox fails with File not found. As stated above for the curly and wget work for the same URL.
I was wondering if there is a specification that defines the correct behavior in this case? Are there good reasons why the request can't be processed by Chrome and Firefox? Also, it seems strange that they don't provide proper feedback.
I think for most cases a download for failing requests makes no sense, but for some cases it would be helpful. One good example where downloading a file even in the error case would be if there is a client that only communicates with the server using some 3rd party format. The client would have to download a generated file for the request. In the case of an error, the client should download a file containing the error description.
For example the RFC7231 states
Response messages with an error status code
usually contain a payload that represents the error condition, such
that it describes the error state and what next steps are suggested
for resolving it.
The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user.
This doesn't forbid downloading in the case of an error.
Edit because of the first answer:
I don't think that this behavior is user friendly and I don't think that user friendliness is really the reason behind this. For example it would make way more sense to show the error code and error message (provided in the header) to the user. Or least indicate the error with an error message like "cannot download the file, because the server responded with an error". There might be servers that can only respond with XML or any other random file format.
What bugs me the most is that both browsers respond with different but arbitrary errors that don't hint any information about the underlying issue.
It might be that this is an undocumented edge case and both Chrome and Firefox just fall back to a default error, but this seems unlikely, especially because this is an edge case that has a special flag in wget.
4XX: Why would you assume a file download if your client did something wrong?
If we assume that an API has an endpoint that replies with a certain file format, it is fair to assume that also the error message including a hint what the client did wrong is provided in that format. So the file can help to fix the client error.
I'm not aware of any specification for that topic.
The behavior should be as user friendly as possible.
4XX:
Why would you assume a file download if your client did something wrong? Furthermore, the client software could not differ between the case of wrong usage(e.g. invalid url) and handling a file download.
5xx:
As you stated most api provide error information, but you could also not differ the case of downloading and for example an internal error providing the file.
You can use such behavior with wget and curl as you mentioned, but its not user friendly nor practical for using such an API programmatically.
The above info in mind, Chrome and firefox just try to be user friendly.
I hope I could somehow answer your question or challenge the idea behind it. :)
Looking at chromium handle download and not 2xx we see:
// The response code indicates that this is an error page, but we don't
// know how to display the content. We follow Firefox here and show our
// own error page instead of intercepting the request as a stream or a
// download.
So Chrome followed Firefox, and both are entirely consistent with the RFCs, the browser knows this payload is unidentified data relating to an error condition, so saving it as the file in question is not an option. Since it is being downloaded, presumably the browser can't display the payload, but in either case has been instructed not to, so displaying it in the error context is not a safe option. Since it is an error there is also a high likelihood that the sender has combined a partial response with an error code meaning that the payload contents may be an incomplete or corrupt representation of data from a 2xx response/etc.
If you look back at wget, --content-on-error is a specific option because it is the wrong thing to do as a general browser. A client side that works with the payload type could examine the errors when it is directly interacting with a server and wget is only providing options to help you debug such an interaction. A normal browser has less features to help emulate other clients for debugging than a text CLI, since a text CLI exists primarily to emulate some other client while debugging.
I was wondering if there is a specification that defines the correct
behavior in this case? Are there good reasons why the request can't be
processed by Chrome and Firefox? Also, it seems strange that they
don't provide proper feedback.
There is no such specification for this, but the chromium project member finds this as a trivial issue and unlikely to be fixed in near future. Instead of they fixing in the chromium they suggest that it should be fixed on the server by sending proper HTTP status.
Response from Chromium Project Member: "This issue has been Available for over a year. If it's no longer
important or seems unlikely to be fixed, please consider closing it
out. If it is important, please re-triage the issue."
Sorry for the inconvenience if the bug really should have been left as
Available.
You can check more details here Issue 479265
What's happening beneath the surface?
I further checked the source code of the chromium to find what actually happening and found that for any non 200 status for downloads, they are simply throwing ERR_INVALID_RESPONSE (Invalid Server Response) error.
To cut a long story short, you have to live with this behaviour of the browser, it is not going to be improved.
Building on #lossleader's answer, it looks like Chromium decided to follow Firefox's decision to not download files if the response was not successful.
It seems like this issue has a history. In 2005 an AOL website had an issue that returned a status code 500 and resulted in users downloading an .exe file. There was a "fix" that simply returns a 404 for responses that trigger a download and with erroneous responses. The corresponding issue can be found here.
There is an open issue from 2008, that complains about this error and states that it would is misleading. The corresponding issue can be found here.
I found a more detailed answer about this on Super User.
I still think that it would be correct to at least offer a choice to the user to download the file nevertheless or at least show a more meaningful error page. On the other hand, in most cases a download for a response code != 2XX is unintended and hints a server error. Therefore it seems that this issue has a low priority for browser vendors and seems "not worth the trouble".
These answers all seem to bypass the fundamental here: You're trying to give a browser-specific interpretation to an error in your code. From my point of view, in all associated cases, your code is failing in some manner without error handling.
4xx error? You've sent a bad request to the server, according to rules you have determined. It's not, technically, the browser's fault.
5xx error? Your server crashed and didn't throw a pretty error. On some types of server, (Django) a 500 error will be a bunch of debug information you probably shouldn't show the user.
Thus what you're asking for is strange from an architectural standpoint; you want to cover up the fact that you've screwed up by modifying the browser's response rather than fixing your code to respond appropriately.
When we use sqlmap, it does everything automatically for finding sql injection of a website. I'm interested in that I send malicious queries directly in my browser and get the results in it, but when I couldn't find anything, I use sqlmap for finding malicious queries. I use the payload that sqlmap gives me and enter it in the vulnerable field of the website in my browser. I want to get all databases of the website in my browser, but I cannot get them. Although sqlmap uses the payload and gives me all databases of the website. Now my question is how to use sqlmap payload in browser manually?
So this is the problem，I have a simple way to sound.
1.you must have burpsuite tools
2.Monitor local 8080 or any port you specify by burpsuite.
3. use the --proxy parameter U of sqlmap. It looks like this.
sqlmap.py -u "URL" --proxy http://127.0.0.1:8080
4.you can get all http requests,then you can test it in your browers
good luck to you!
I have developed an app that use a RESTful API using JSON:
- Server side: PHP
- Mobile side: JavaScript or AS3 - XHTTPRequest (AJAX)
Each time I request data to server from mobile I send "{user, password, info request}", and I have developed my own algorithm to encrypt these data before sending them.
Probably I can use HTTPS to send data in a safer way, and I can use SESSION info to avoid the need of sending user/password in each request.
This is not the problem, the problem is that I have the sense of being reinventig the wheel because this issue must be solved already in a million ways (almost every app needs info exchange with a server through HTTP/HTTPS).
I have found lots of link in stackoverflow talking about using JSON/REST but no one talking about an specific standard protocol.
I have found other places with info:
http://openmobilealliance.org/
https://core.telegram.org/mtproto
wikipedia: Wireless Application Protocol
But I am not sure about the better way for doing it.
Any sugestion?, any tutorial, specification, example or case of use link?
Thanks a lot.
J. Pablo.
Firebase is one that I've heard of and haven't used yet. https://firebase.google.com/
I am currently building one using JWT and Laravel, and have been pretty happy with it. Using this link as a guide: https://scotch.io/tutorials/role-based-authentication-in-laravel-with-jwt
the box appears in below snapshot is neither alert box,prompt box nor confirm box. then what is this? how can i create the same thing like this?
It's a BasicAuth prompt, if your server return a request for BasicAuth it will get handled by the browser.
It happens when the browser receives a response with a header that looks like this, "insert realm" can be almost anything:
WWW-Authenticate: Basic realm="insert realm"
Usually the web browser handles it by itself and shows that kind of prompt. By the way it's unrelated to the web server as it's part of the protocole. If you happen to run an application server, you'll have to send the header above in a response and expect an Authorization header back from the "web client".
If you run apache, nginx, you can check simply for BasicAuth and you should be able to find documentation on how to set it up.
Read more here: BasicAuth
If you have enough courage you can read the RFCs
This is a simple HTTP Authentification, like the one you can setup with a ".htpasswd" file on Apache and so on.
You can't do it with Javascript (it's on server-side), in PHP it would be like this
I called attached code below in WinJS app and keep getting this error 405 Method Not Allowed. I have changed the method property to "POST" , still the same thing. Some of the guys saying it is to do with the permission so I am trying to set the credential in the uploader. This is an internal app so we assume this should carry the Windows Authentication. But at the moment, I could not find how. Can anybody help?
uploader.createUpload(endpoint, file)
.startAsync()
You haven't narrowed down the problem to the point where you should be worrying about how to express what you need with BackgroundTransfer APIs yet - you need to figure out what you need to express, first.
If you have access to good documentation or a knowledgeable owner of this internal service you're connecting to, your first step should be consulting that to figure out what exactly the HTTP request (and the associated credential headers) should look like.
If you don't have access to that, the second best starting point is to take an existing, working client of this service you're uploading to and use a networking capture software (Fiddler, for example) to take a look at what the request it's sending looks like.
Once you've figured out the specific HTTP method and server credentials you need to use, you can tell BackgroundTransfer to use them by setting the method and serverCredential properties of your uploader object before creating your uploads.