Let say I have a bulk of text which needs to be pushed to a server thru REST api interface.
I also have a large volume of data/records to get pushed.
I am thinking that if we use compression technique then we can reduce the latency of data transfer.
Can this be done by including "Content-encoding' in my REST api request though the public API provided my the server did not specify CE option?
Edit
In particular I need to figure out how to do this using rest-client gem in ruby.
Yes the REST API allows the use of compression on the request and the response, using the standards defined by the HTTP 1.1 specification. And this is by using Accept-Encoding to tell the server what compression the client supports and the header Content-Encoding to describe the compression of the body. You may also check those links :
Enable HTTP Compression for Requests
JSON REST Service: Content-Encoding: gzip
WCF REST Compression
Related
In client-server communication, why server always respond (i.e. Http Response) to user in HTML format and not in any other format?
In HTTP Client-Server communication, it is possible to do a content-negotiation if the server supports different styles of responses like XML, JSON or TXT other than plain old HTTP responses. All that the client has to do is to send the desired format in Accept headers that is sent in the HTTP request. This is one of the core concepts of RESTful interface envisioned by Roy Fielding.
I have Spring boot Rest APIS, but i want make those APIS Response as per the Client Requested Format.
For Instance :
Rest APIS Return Response By default In Json format. But Client Want to in XML formate or any other formate.
In the above situation how can i make my APIS dynamically Retunr the Response as per the Client requested format.
can any tell how can i do this.
Thanks in advance.
What you are talking about is Content Negotiation - Here's a Baeldung article that describes how you might use Jackson libraries to handle both XML and JSON data,
https://www.baeldung.com/spring-mvc-content-negotiation-json-xml
You need to devise a content negotiation strategy - very often, that is the use of the Accept header. Your API then has to respect this header and return the appropriate content, which might mean your API contracts having certain attributes to allow it to easily serialize to JSON/XML.
The article linked above links to a github repo that shows how this might be achieved - https://github.com/eugenp/tutorials/tree/master/spring-mvc-basics
I have a webpage that has JS, CSS, and font assets. The page has to do some heavy processing before determining the HTTP Status code and headers for its response.
I'd like to use HTTP/2 Push to send the assets to the browser without waiting on this heavy processing. The timeline would look something like this:
Client requests index.html
Server sends PUSH_PROMISES for script.js, styles.css, and font.woff2
Server sends HTTP headers and data for the assets above
Server does some heavy processing to determine index.html response...
Server sends HTTP headers and data for index.html
Is this possible? Based on my understanding of Server Push in the HTTP/2 spec, it appears possible. However, it's my first time diving into the HTTP/2 spec, so I could definitely be missing something.
Yes that’s totally allowed and it’s possible in Apache for instance as detailed here: https://icing.github.io/mod_h2/earlier.html
Or an example with Node is given here: https://github.com/bazzadp/http2-in-action/blob/master/Listing%205.3/app.js
Other servers may allow this too, but many servers use preload HTTP headers as signals to push so that needs the response to be sent sent back to show the header.
An extra 103 Early Hint response has been defined which can be sent back early with these headers while your main response is being processed, however support of this is poor not least because some implementations will be confused to get back two responses (a 103 followed by a 200).
What you want to do is possible, but the details of how to do it depend on the technology that you have chosen.
Your application needs to have explicit HTTP/2 APIs to push assets to the client.
For example, if you use Java and Servlet, you need to use Servlet 4.0 which has introduced the PushBuilder APIs to explicitly push assets, and this can be done independently from the main resource response, like you would like to do.
I'm sure other technologies such as NodeJS have similar APIs that you can leverage, but you have to check with the technology you are using.
In chunked downloading, there are extensions on each chunk that can be leveraged when coming to a browser. the last chunk can also contain optional headers defining stuff like content-length if we streamed a big file through, we can provide that information at the very end in the form of a http header.
How does this work in http/2? Are there even extensions or headers in last piece. I see there is Data payload but there is no extensions nor optional headers AFAICT. I only see padding.
Maybe a better question is do browsers even
leverage the optional headers in the last chunk?
leverage extensions in each chunk?
Perhaps programs may care but if it is a progam, I believe in http/2, the server just defines the api better perhaps and uses a push mechanism after response+data has been sent maybe?
How would one send optional headers in this new http/2 world though if I was a server defining an api for clients?
I was trying to use wireshark to capture a download trace but chrome seems to use QUICK and I can't seem to decrypt the SSL with wireshark for this use case when I use firefox and drive.google.com to download a file(it stays encrypted while in the same trace, I actually saw some http2 traffic in TLS for some other service working just fine). Using the "(Pre)-Master-Secret log filename" seems to only work half the time and I am not quite sure why. I end up having to restart everything and re-run my cases.
Also, in the Server hello, h2 was the protocol selected but then no http2 packets appear when I filter to ip.addr=(server hello google ip) and tcp.port=443
thanks,
Dean
In chunked downloading, there are extensions on each chunk that can be leveraged when coming to a browser. the last chunk can also contain optional headers defining stuff like content-length if we streamed a big file through, we can provide that information at the very end in the form of a http header.
In theory (i.e. standard) you have the extensions and the possibility to add non-essential(!) headers at the end. In practice these feature are not used. I'm not aware of any chunk extensions which are defined which means that browsers simply ignore them. And the example trailer defining a content-length makes no sense because with chunked encoding any content-length header should be ignored. There might be some third party libraries which make use of trailers. But since support for trailers would need to be declared up-front by the client (using TE:trailers header) browsers don't use it.
If I understand HTTP/2 correctly chunk extensions are simply gone (nothing lost, they were never used). Trailers are still possible, i.e. you could add headers after all data are sent, see RFC7540: 8.1 HTTP Request/Response Exchange.
I wonder if AJAX can use protocols other than HTTP or HTTPS.
Ajax means XMLHttpRequest. Just as you don't have to use XML with XHR, you also don't have to use HTTP.
Despite its name, XMLHttpRequest can be used to retrieve any type of data, not just XML, and it supports protocols other than HTTP (including file and ftp).
From the W3C XMLHttpRequest spec (emphasis added):
The XMLHttpRequest object implements an interface exposed by a scripting engine that allows scripts to perform HTTP client functionality, such as submitting form data or loading data from a server. It is the ECMAScript HTTP API.
The name of the object is XMLHttpRequest for compatibility with the Web, though each component of this name is potentially misleading. First, the object supports any text based format, including XML. Second, it can be used to make requests over both HTTP and HTTPS (some implementations support protocols in addition to HTTP and HTTPS, but that functionality is not covered by this specification). Finally, it supports "requests" in a broad sense of the term as it pertains to HTTP; namely all activity involved with HTTP requests or responses for the defined HTTP methods.
The available protocols beyond HTTP and HTTPS are non-standardized, so they depend on the specific environment1 you're using. That is, all compliant XHR implementations must support HTTP and HTTPS, but are not required to support any other specific protocols. That means that you might find that Internet Explorer supports
1Such as, which version of which browser (Safari vs Firefox vs Chrome vs IE vs Opera vs...), or which server-side implementation (V8 vs Rhino vs...)
XMLHttpRequest (XHR) is an API available to web browser scripting languages such as JavaScript. It is used to send HTTP or HTTPS requests to a web server and load the server response data back into the script.
from wikipedia