For a PUT or POST (for example), I would like to specify to the server that I don't want any content returned in the response, even if it normally would. Essentially I'm looking for a way to perform blind inserts/updates, and was trying to avoid unnecessary response payloads if I have no intention of using them.
I thought maybe Accept: none as a request header (or something similar) might be an option, but couldn't find anything to support that.
Is there a standard way to specify this in an HTTP request, or do I have to just live with a little extra content in the response?
I think a minimal response is necessary to know if the request was handled correctly by web servers or if there was errors, even if it has no data other than status code and HTTP headers.
That said, you can use HEAD HTTP command to make a GET request having a response without the message body (you get back only headers). But this, AFAIK, doesn't work with POST or PUT requests.
Regards.
You might be interested in the proposal outlined in https://datatracker.ietf.org/doc/html/draft-snell-http-prefer-18.
Related
I know that XMLHttpRequest and ServletRequest are not different in theory by searching similar questions.
But some details confuse me.
Fox example, if I send an XMLHttpRequest to the server, how does the client know the response is for the XMLHttpRequest rather than for the ServletRequest?
How does the client distinguishes the response type?
Otherwise, on the server side, when I call method:
response.getWriter().write(str);
Will the argument str be present on the browser?
This may be of help to you.
while the standard HTTP request makes a 'synchronous' call and must wait for the response and makes a page-reload (you always get a new html-page to display) a XMLHttpRequest may be used sync (not typical) and async (the better way) without a page-reload. you may ask for the response with javascript and the response is usually xml- or json-data that you may process with js and update parts of your page through the use of dom-methods that manipulate your document ... so you don't need an entire page-reload because all of that is running in the 'background' ...
This should also help with how the two requests are treated differently by servers and clients.
I am writing a webserver. I implemented GET and POST (application/x-www-form-urlencoded, multipart/form-data) and that works fine.
I am thinking of adding a RESTful module to the server. So had a look at some stuff that's out there and got opinions about when to PUT, POST, and GET.
My question is: what encoding (application/x-www-form-urlencoded, multipart/form-data) does PUT support (per the HTTP specifications), or can it handle both?
I am trying to make the webserver as standard specific as I can without shooting myself in the foot.
The limitation to application/x-www-form-urlencoded and multipart/form-data is not in the HTTP standard but in HTML. It's the only formats that can be created by an HTML form. From HTTP point of view, you can use any format, as long as you specify it to the server (Content-Type header) and obviously that the server can understand it. If not, it reply with a 415 Unsupported Media Type status code.
See:
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.4
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.16
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7
HTTP PUT can have whatever content-type the user wishes (the same as for all other HTTP methods).
I have a program that is supposed to interact with a web server and retrieve a file containing structured data using http and cgi. I have a couple questions:
The cgi script on the server needs to specify a body right? What should the content-type be?
Should I be using POST or GET?
Could anyone tell me a good resource for reading about HTTP?
If you just want to retrieve the resource, I’d use GET. And with GET you don’t need a Content-Type since a GET request has no body. And as of HTTP, I’d suggest you to read the HTTP 1.1 specification.
The content-type specified by the server will depend on what type of data you plan to return. As Jim said if it's JSON you can use 'application/json'. The obvious payload for the request would be whatever data you're sending to the client.
From the servers prospective it shouldn't matter that much. In general if you're not expecting a lot of information from the client I'd set up the server to respond to GET requests as opposed to POST requests. An advantage I like is simply being able to specify what I want in the url (this can't be done if it's expecting a POST request).
I would point you to the rfc for HTTP...probably the best source for information..maybe not the most user friendly way to get your answers but it should have all the answers you need. link text
For (1) the Content-Type depends on the structured data. If it's XML you can use application/xml, JSON can be application/json, etc. Content-Type is set by the server. Your client would ask for that type of content using the Accept header. (Try to use existing data format standards and content types if you can.)
For (2) GET is best (you aren't sending up any data to the server).
I found RESTful Web Services by Richardson and Ruby a very interesting introduction to HTTP. It takes a very strict, but very helpful, view of HTTP.
I've read the w3.org spec on the 'HEAD' verb, and I guess I'm missing something. I can't see how it would be useful.
Is the HTTP 'HEAD' verb useful in web development?
If so, how?
From RFC2616:
This method (HEAD) can be used for obtaining
metainformation about the entity
implied by the request without
transferring the entity-body itself.
This method is often used for testing
hypertext links for validity,
accessibility, and recent
modification.
The reason why HEAD is preferred to GET is due to the absence of the message body in the response making it using in scenarios where you want to determine if the content has changed at all - a change in the last modified time or content length usually signifies this.
Also, a HEAD request will provide some information about the server setup (whether it is IIS/Apache etc.), unless the server was masked; of course, this is available in all responses, but HEAD is preferred especially when you don't know the size of the response. HEAD is also the easiest way to determine if a site is up or down; again the irrelevance of the message body makes HEAD the ideal candidate.
I'm not sure about this, but RSS/ATOM feed readers would use HEAD over GET to ascertain if the contents of the feed have changed.
The HTTP HEAD can also be used to pre-authenticate to web server, before you do HTTP PUT/POST of some large data. Without the first HEAD request, you would be sending the large data to web server twice (because the first request would return 401 unauthorized reponse with WWW-authenticate header).
It's mainly for browsers and proxies to determine whether they can use a cached copy of the web document without having to download the whole thing (which would rather defeat the purpose of a cache).
I'm wondering: if I were a a router, packet inspector, firewall, or other packet-sniffing device (which I'm glad I'm not) would I be able to tell the difference between a traditional HTTP request and an XMLHttpRequest? Less theoretically, is it possible that some ISP or (let's say) cell phone data provider could restrict XMLHttpRequest traffic without interrupting HTTP service?
Thanks.
There's nothing at the packet level to distinguish them because and XMLHttpRequest is an HTTP request. The XML bit refers to the fact that if the response is of an xml Content-Type then the responseXML method will return a DOM Object.
To the best of my knowledge, there is no fundamental difference - so from the point of view of a router etc. you can't tell in general.
But I do believe that most popular Javascript toolkits will add an HTTP header to their XMLHttpRequests to identify them as such. I forget the name, though...
EDIT: Here's an example (top Google hit for "jquery xmlhttprequest header", no quotes) that shows that jQuery apparently sets X-Requested-With to "XMLHttpRequest".
at packet, network, session levels: no.
at application level, that is with an HTTP-specific device like a filtering proxy, maybe.
i'd check the HTTP request headers. they might (just might) have some differences. but i'm sure any difference there would be very browser-specific, and quite probably the right JavaScript code could insert the appropriate headers to make it totally indistinguishable.
in short: check the HTTP headers; but don't expect it to be general, much less useful.