When I make an HTTP request with the method HttpSendRequest of the WinINet API, and the response sends "302: Moved Temporarily", the WinINet API automatically follows the redirection instruction and makes a new request.
So, How to prevent HttpSendRequest to follow redirects (30x Status Codes)?
I don't want't to make two requests... I wan't to get the the first response it got with the status code 302 in it's header.
I found a flag INTERNET_FLAG_NO_AUTO_REDIRECT that I must pass to HttpOpenRequest.
But, it isn't working....
Redirection can be prevented if you are able to use WinHTTP instead (link).
Try using INTERNET_FLAG_NO_AUTO_REDIRECT in the call to HttpSendRequest. Sounds like you're trying to use it from HttpOpenRequest.
I use this flag with InternetOpenUrl, and it works properly in that call.
Seems like WinInet behavior largely depends of lpszAgent specified in the InternetOpen function call. When you pass "Mozilla/5.0 (compatible)" all redirects are ignored and you will get RAW HTML result when reading response with InternetReadFile.
On the other hand, if you need "redirected" output, you must specify your application name in the Agent argument, for example "ConEmu Update".
Related
I'm creating a TODO list app with nodejs and I need an option to delete a todo record. So I've created an HTML form that contains a delete button but I can only use POST as the method. actually my code is working fine but are there any problems with using POST to DELETE records?
No there isn't. Apart from GET and POST requests, most of the other HTTP method serve only semantic purposes. Except for some notable examples such as OPTIONS which is use to communicate supported methods. Using correct HTTP verbs will make your application / API easier to understand.
The same goes for HTTP status code. Functionality-wise, it doesn't really matter if you send a 200 (OK), 201(Created), or 202 (Accepted) for a successful request. However, sending the correct status code can avoid necessary confusion.
As far as I know, no. There're no hazards of using HTTP post method instead of DELETE. You can see how it's used in deletion here
One difference is that users might be tricked into making the POST request and inadvertently deleting an entry, if they are lured onto a malicious web page that contains an auto-submitting HTML form
<form method="POST" action="<your deletion endpoint>">
(Whether that is possible depends on the content type that your deletion endpoint expects.)
A DELETE request, however, cannot be forged in such a way. A malicious web page could create a DELETE request only with fetch or XMLHttpRequest, and because of the CORS protocol the browser would refuse to carry that out (unless your server explicitly allows it through a suitable CORS preflight response).
I'm playing with core-ajax element and I need to extract http status code from ajax response. I was looking for it in this.$.ajax.* but cannot find it anywhere. I believe it must be exposed somewhere, right?
Huh, it looks like it's not currently exposed as a field. I can see where having easy access to the status for the current request would be valuable, patches welcome!
You could listen for either the core-response, core-error or core-complete event depending on your use case. Each of them receives an event with an xhr field, which has the status at xhr.stats.
Why if I submit an URL like:
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER ,
I get an error that says "Bad Request - invalid URL HTTP Error 400. The request URL is invalid." ?
The default maximum length of a URL is 4096 in IIS. You may well be breaching that with the comment posted by the user. Generally, the best way to transfer that kind of data is by POST rather than in a URL. You can either trim the comment to a more suitable size of increase the maxUrl value in the requestLimits section of your IIS config: http://msdn.microsoft.com/en-us/library/ms689462%28v=vs.90%29.aspx
Firstly, HTTP 400 error is intended for cases when the client has made an error. As you've noticed yourself it's a bad request error. So that means possibly due to bad syntax the request can not be carried out. As Mike Brind mentions, you're most probably exceeding the maximum length of the URL (the default value anyway)
Secondly, why are you trying to "submit" a long post by URL? Use the POST method instead. A way to do this is by using Jquery's Post method to do this. See this. Or simply by calling the form's submit method through OnClick method or however the user is submitting the form.
POST is perfect for transmitting large amounts of data. So submitting data from the client side, the easiest way by far is to use POST to archieve this.
As you have yourself stated in the Question code part,
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER
the Long comment by user, must be inside the limits that are in the web.config file of your website.
Secondly, no Server would allow a very Long Url thinking that the user might be trying to post a malware. Also, using short URLs is good for Data transfer as they consume less data.
From the limits on Requests one would easily come to understand that the URL must be less than 4096bytes, only 4KB. So do you think, all that URL would be 4KB?
As Mike has suggested to use POST request to send the long data, I would also suggest you to use HttpPost requests to send this type of long data. This way, Browser would encrypt the data and sending it as an attachment to the request.
I'm trying to replicate a request I make on a website (ie zoominfo.com) using the same http POST parameters using chrome rest console, but it fails for some reason. I'm not sure if there is a missing field or it's not working because the origin of the request isn't valid.. can someone point me out in the right direction? Below is a detailed explanation of the experiment:
ORIGINAL CASE
basically if I go to zoominfo.com (registered and all) I see a form page that I need to fill:
if I hit enter.. the site makes an ajax call. If I open the chrome web dev tools, and open the network tab, I see the details of the ajax call:
notice the body of the POST has the name John Becker in it:
{"boardMember":{"value":"Include","isUsed":true},"workHistory":{"value":"CurrentAndPast","isUsed":true},"includePartialProfiles":{"value":true,"isUsed":true},"personName":{"value":"john%20becker","isUsed":true},"lastUpdated":{"value":0,"isUsed":true}}
the response is shown under the respones tag:
WHAT I'M TRYING TO DO
basically replicate what i've done above using a REST console (note: so there is nothing illegal here.. i'm just replacing a chrome browser action with a rest client action.. i'm not hacking anyone and i'm not getting information I can't get the normal way, but if someone feels otherwise.. please let me know)..
so I plug in the same parameters as above into the rest console:
now i'm not sure about authentication.. but just to be safe, i entered the same user name and pwd i have for the site into the REST console:
but then I keep on getting an error as a response to my rest console's request:
UPDATE: CORRECT ANSWER:
so according to JMTyler's answer.. I had to simply include criteria in the RAW body, and convert it to url encoding.. in addition to that, I had to explicitly set the encoding in the rest console body..
looking at the chrome inspector more closely, it turns out that I simply had to click on view source:
to get the url-encoded value that I needed to put in the RAW body in the rest console:
I also had to set encoding to gzip,deflate,sdch and things worked fine!
The form is posting all that JSON under the field criteria. You can see this in the screencap of the chrome dev console you posted.
Just start your raw body in rest console with criteria= and make sure the json has been url-encoded. That should do it.
No authentication is needed because none is passed through the headers in your screencap. Any cookies you have when you load the page normally will also be loaded through rest console, so you don't need to worry about explicitly setting them.
Reading your problems I'll make an educated guess:
zoominfo does not provide an RESTful API.
Rest-Console understands and uses HTTP Authentication, which is different from the authentication handler zoominfo implemented.
A possible way to work around may be:
Make a call to the login-page via rest console. you'll get back cookies and a lot more.
In subsequent requests to zoominfo be sure to include those cookies (likely holding some session information) in your request, therefore acting like a browser.
I am trying to understand how POST and/or GET methods work in terms of the actual browser.
I am attempting to contact an API which requires API key, method you wish to use on their side, and an IP address at the minimum.
My original idea was to do something like this:
I feel like I'm on the right track, it does something and gets an error as opposed to telling me the page does not exist. I'm expecting either JSON or XML in response as the API supports both but instead I get this error:
This page contains the following errors:
error on line 1 at column 1: Document is empty
Below is a rendering of the page up to the first error.
Upon studying the documentation of the API more, I found something saying that methods are called using HTML form application/x-www-form-urlencoded and the resuource models are given as form elements.
I tried researching what that means to see what the problem was and found this site http://www.w3.org/TR/xforms11/ but I'm still unclear.
Ideas?
It seems to mean that the application is expecting a POST method but you're doing a request with a GET method (when you use the querystrings).
Since you can't just do browser requests using POST using the address bar, you may need to:
Construct a simple JS function that does a xmlhttprequest request using that method instead, and running it from the console;
Create a simple HTML page that automates the above process, allowing you do make POST calls;
Using CURL instead, which is a great tool for testing those kinds of requests.