Regarding this question and also many documents have stated that sending a PUT request directly via form in browser is impossible due to security reason.
However, What I am seeing in Backbone is that it could still send a direct PUT request via browser without a workaround like adding a hidden form field.
And they're confusing to me. Is there anything that I'm missing here?
A form can only send a GET or a POST request, as set in the method attribute.
However, Backbone delegates its requests to jQuery.ajax by default (or whatever you want via Backbone.ajax) which itself wraps XMLHttpRequest, an object that can send PUT/DELETE/PATCH requests.
From https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
XMLHttpRequest is a JavaScript object that was designed by Microsoft
and adopted by Mozilla, Apple, and Google. It's now being standardized
in the W3C. It provides an easy way to retrieve data from a URL
without having to do a full page refresh. A Web page can update just a
part of the page without disrupting what the user is doing.
XMLHttpRequest is used heavily in AJAX programming.
many documents have stated that sending a PUT request directly via browser is impossible due to security reason
Citation please.
Backbone sends a PUT just like it sends any other request, with jQuery,
Backbone.ajax({
type: 'PUT'
...
});
It is just some server side langauges,like PHP, that have problems with receiving a PUT request.
The hidden form field is used when posting from a <form>. Backbone uses javascript.
Related
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));
Regarding to a static link on a web page, the browser will issue GET or POST request to the web site, depending on whether a form of parameters attached.
However, I want the browser to issue a PUT request for that link, how can I do that? I know that Ajax could do it, but I don't want to use Ajax.
I want the browser to issue a PUT request for that link
it seems that PUT and DELETE are currently unsupported in html forms, according to this submission to the w3.
I know that Ajax could do it
Not always true. Because PUT and DELETE are at times unsupported by some browsers, ajax cannot consume them without making a dummy param to trigger a real PUT or DELETE server side, which gives the illusion of full HTTP support by ajax.
In the current HTTP spec, the URL fragment (the part of the URL including and following the #) is not sent to the server in any way. However with the increased spread of AJAX, which uses the fragment to maintain some form of state, there are a lot of situations where it would be useful for the server to have knowledge of the URL fragment at request time.
For example, if you go to http://facebook.com, then click a user name in your stream, the URL will become http://faceboook.com/#!/username - to allow FB to update your page without reloading all of its bootstrap JS and HTML. However, if you were to reload this with your browser, the server would have no way of seeing the "#/!username" part of the URL, and therefore could not pre-render the content for you. This forces your browser to make an extra request once the client Javascript has loaded and parsed the fragment.
I am wondering if there have been any efforts or proposals towards creating a standard mechanism to achieve this.
For example, there could be a standard HTTP header, which would be sent with the value of the URL fragment - any server which cared about such things could then have access to it.
It seems like this would be a very useful thing for the web-application community as a whole, so I am surprised to not have heard anything proposed. Perhaps I missed it though.
Imho, the fragment identifier really is not a good place to store the state, it has been designed for something else.
That being said, http://www.jenitennison.com/blog/node/154 has a good discussion of the whole subject.
I found this proposal by Google to make Ajax pages crawlable, but it addresses a more constrained set of use cases. Specifically, it creates a way to replace the URL fragment with a URL parameter to obtain the same HTML output from the server as would be generated by a client visiting the equivalent URL with the fragment. However, such URLs are useless for actually running the Ajax apps, since they would necessitate a page reload every time.
Webkit Bug 24175 - URL Redirect Loses Fragment refers to Handling of fragment identifiers in redirected URLs which may be of interest.
A suggestion for a future version of HTTP may be to add an (optional)
Fragment header to the request, which holds the fragment identifier.
Even simpler may be to allow an HTTP request to contain a fragment
identifier.
I want to be able to send a simple http post from my firefox extension to my ASP.NET application. From the client side, I have used XMLHTTPRequest by sending the post with the url: http://localhost:15227 which is the url on my ASP.NET app.
What do I need to do to receive a remote request from ASP.NET please?
thanks
This page from Apple has a pretty good example of how to send/receive data using a raw XmlHttpReqeust object (as opposed to a JavaScript library).
You can get the value of the response from the responseText property once you know the response came back successfully. Specifically take a look at where the processReqChange function is defined, your code will go in there (or your equivalent of that function).
If you want to explore JavaScript frameworks, take a look at how much less code you need if you use jQuery get (for example).
I am not gettng the RESTful thing. Yes, I know how to send a GET request to my app from my browser. It's through URL linking.
<a href="/user/someone">
And can also send POST requests through form method.
<form method="post">
Beside that I know browsers sometimes send HEAD command to figure out page status, but on which the end user has no control.
Then what are those DELETE and PUT commands I am reading of? How do you send, for example a DELETE command from your browser to your RESTful application?
The HTML 4.01 specification describes only GET and POST as valid values for the method attribute. So in HTML there is no way of describing other methods than this by now.
But the HTML 5 specification (currently just a working draft) does name PUT and DELETE as valid values.
Taking a look into the XMLHttpRequest object specification (currently just a working draft too) used for asynchronous requests in JavaScript (AJAX), it supports the PUT and DELETE methods too, but doesn’t say anything about the actual support by current browsers.
To simulate PUT and DELETE, frameworks like Rails instead build forms like this:
<form action="/users/1/delete" method="post">
<input type="hidden" name="_method" value="delete" />
<input type="submit" value="Delete user 1" />
</form>
This is actually a POST form, but using the hidden _method input to tell the server which method was really intended. You could implement this support on any other web framework as well.
#C Moran is right: if you want to be truly RESTful, a browser isn't an ideal client, due in part to the lack HTTP methods beyond GET and POST. However, if you really want to do it from a browser, you can use AJAX to send PUTs and DELETEs, e.g. YUI's Connection Manager allows you specify any of the following HTTP methods:
GET
POST
HEAD
PUT
DELETE
I've heard that DELETE and PUT is not fully supported in all browsers (I didn't check it). Rails is doing workaround - it is sending POST with a hidden field containing real method. So it really uses only GET and POST and on server it reads this hidden field and reacts on it.
A POST doesn't have to be through a form. The best way to learn about this, and also GET, PUT and DELETE is to use a ReST client to make your HTTP requests and see the responses. I recommend you download the nifty little python client from http://restclient.org/
A browser is (as of now) not your best tool to use while you are acquainting yourself with ReST. A client like the one above will allow you to "see" your HTTP requests and responses.
Flash based applications (or Flex) can work on lower levels, like open sockets. They can also do PUT/DELETE (though Flex in particular is known to have problems with http headers.
So I guess I'm saying it depends on your client technology. In particular, you could embed a small flash object that would do the communication for you if your browser doesn't support it (or you don't want to implement cross-browser support).
DELETE and PUT are HTTP verbs, say REST commands that shall delete or update an object on the server.
Using them in the browser can be done in different ways. You can't send them through HTML, but you can send an JavaScript Ajax request, if you want to use them programmatically.
If you only want to explore the API or test some calls, and you want to do this from the browser, you can use browser plugins like RESTED for firefox.
For manual and automatic testing you can use Postman as a full featured API test environment.
On Windows, you can use the PowerShell script httprepl to send different HTTP RESTful API usages.