HTTP PUT:
PUT puts a file or resource at a specific URI, and exactly at that URI. If there's already a file or resource at that URI, PUT replaces that file or resource. If there is no file or resource there, PUT creates one. PUT is idempotent, but paradoxically PUT responses are not cacheable.
HTTP 1.1 RFC location for PUT
HTTP POST:
POST sends data to a specific URI and expects the resource at that URI to handle the request. The web server at this point can determine what to do with the data in the context of the specified resource. The POST method is not idempotent, however POST responses are cacheable so long as the server sets the appropriate Cache-Control and Expires headers.
The official HTTP RFC specifies POST to be:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
HTTP 1.1 RFC location for POST
Difference between POST and PUT:
The RFC itself explains the core difference:
The fundamental difference between the
POST and PUT requests is reflected in
the different meaning of the
Request-URI. The URI in a POST request
identifies the resource that will
handle the enclosed entity. That
resource might be a data-accepting
process, a gateway to some other
protocol, or a separate entity that
accepts annotations. In contrast, the
URI in a PUT request identifies the
entity enclosed with the request --
the user agent knows what URI is
intended and the server MUST NOT
attempt to apply the request to some
other resource. If the server desires
that the request be applied to a
different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make
its own decision regarding whether or not to redirect the request.
Additionally, and a bit more concisely, RFC 7231 Section 4.3.4 PUT states (emphasis added),
4.3.4. PUT
The PUT method requests that the state of the target resource be
created
or replaced
with the state defined by the representation
enclosed in the request message payload.
Using the right method, unrelated aside:
One benefit of REST ROA vs SOAP is that when using HTTP REST ROA, it encourages the proper usage of the HTTP verbs/methods. So for example you would only use PUT when you want to create a resource at that exact location. And you would never use GET to create or modify a resource.
To decompress a gzip format file with zlib, call inflateInit2
with the windowBits
parameter as 16+MAX_WBITS
, like this:
inflateInit2(&stream, 16+MAX_WBITS);
If you don't do this, zlib will complain about a bad stream format. By default, zlib creates streams with a zlib header, and on inflate does not recognise the different gzip header unless you tell it so. Although this is documented starting in version 1.2.1 of the zlib.h
header file, it is not in the zlib manual. From the header file:
windowBits
can also be greater than 15 for optional gzip decoding. Add
32 to windowBits
to enable zlib and gzip decoding with automatic header
detection, or add 16 to decode only the gzip format (the zlib format will
return a Z_DATA_ERROR
). If a gzip stream is being decoded, strm->adler
is
a crc32 instead of an adler32.
Best Answer
Will the browser automatically gzip-encode your data for you? The short answer is no.
The long answer is that some user-agents can do things like this, but you definitely can't rely on it. The apache mod_deflate docs state:
So, no, that's not going to work. You'll need to generate the appropriate HTTP request message yourself. The appropriate header in this case is
Content-Encoding: gzip
and NOTContent-Type:
because the content itself isapplication/json
, you're just looking to encode the entity body of your HTTP request message for transport.Note that you need to also add the appropriate
Content-Length:
header specifying the size in bytes of the message entity body after compression -OR- send your HTTP message usingTransfer-Encoding: chunked
and forego the content-length specification.On the receiving end, you can instruct
mod_deflate
to use an input filter to decompress the information:This is a bit heavy handed if you're only receiving compressed message bodies for a couple of resources. Instead, you should probably just use the client-side script to check for the
Content-Encoding: gzip
header and decompress the request body manually. How to do this in say, PHP, is another question entirely. If you need details for that you should post another question.