Some of the acronyms you will encounter in deciphering HTTP headers include: HTTP, MSIE, CLR Fields in the headers let browsers and servers communicate. You set them up with .setHeaderField or more specialised methods. These codes are idiotic. In a sane universe, should just contain the browser name and version. For example:
HTTP Headers that Browsers Send Servers | ||
---|---|---|
Field | Typical Value | Meaning |
User-Agent: | Java.exe default ⇒ Java/
1.8.0_131
Last revised/verified: 2016-12-04
Firefox ⇒ Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Last revised/verified: 2017-08-09 Chrome ⇒ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Last revised/verified: 2017-08-09 Opera ⇒ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 OPR/48.0.2685.52 Last revised/verified: 2017-10-26 Opera caches with turbo mode so you never nee the User-Agent. Safari ⇒ Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 Last revised/verified: 2015-09-27 SeaMonkey ⇒ Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 Last revised/verified: 2015-12-10 Avant ⇒ Mozilla/5.0 (Windows NT 6.1; WOW64; Avant TriCore) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36Last revised/verified: 2015-12-10 Edge ⇒ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586 Last revised/verified: 2016-05-27 IE (Internet Explorer) 11.0 ⇒ Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; Avant Browser; rv:11.0) like Gecko Last revised/verified: 2015-12-10 IE 9 ⇒ Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; Avant Browser) IE 8 ⇒ Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; Avant Browser; SLCC2; .NET CLR 2.0.50727;. NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC (Personal Computer) 6.0; .NET4.0C; .NET4.0E) Last revised/verified: 2011-02-03 IE 7 ⇒ Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media CenterPC5.0; .NET CLR 3.0.04506) Netscape ⇒ Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.5pre) Gecko/20070710 firefox/2.0.0.4 Navigator/9.0b2 |
Which browser being used/simulated |
Host: | localhost:8081 | destination url, server:port. |
Accept: | application/xhtml+voice+xml;version=1.2,
application/x-xhtml+voice+xml;version=1.2,
application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
or text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 |
MIME (Multipurpose Internet Mail Extensions) types the browser is willing to accept. The encoding of this field, is described in RFC 7230 section 14. and in the more friendly w3.org version. Roughly the q numbers define your preference. The higher the number the higher the preference. Default is 1. The q applies to the preceding MIME. You set this with URLConnection. setRequestProperty( Accept, …); not accept as the Sun docs erroneously suggest. |
Accept-Language: | en | Language the browser in willing to accept. |
Accept-Charset: | windows-1252, utf-8, utf-16, iso-8859-1;q=0.6, *;q=0.1 | Character set encodings the browser is willing to accept. |
Accept-Encoding: | deflate, gzip, x-gzip, identity, *;q=0 | compression schemes the browser is willing to accept.
|
Referer: | http://mindprod.com/jgloss/http.html. However, if the page is loaded locally from hard disk, this field will be missing. | the web page that contained the link that triggered this request. |
If-Modified-Since: | Mon, 06 Feb 2006 01:24:23 GMT (Greenwich Mean Time) | Only bother with the request if the file has changed since this date, otherwise the browser already has a copy in cache. If the file has not changed, you will get a 304 not modified response code. |
Connection: | Keep-Alive | requests server keep the socket open for further messages. It is true by default in HTTP 1.1, so you don’t need to use it. |
Keep-Alive: | 300 | requests server keep the socket open 300 seconds for further messages. |
Pragma: | no-cache | requests getting a fresh copy from the server, rather than from a cache. |
Content-Type: | application/x-www-form-urlencoded | MIME type of the payload to the server. |
Content-Length: | 114 | length in encoded bytes of the payload to the server. |
Beware using HttpURLConnection.setFollowRedirects ( false); This reportedly causes trouble in recent JDKs (Java Development Kits). When it is set true, it will not automatically follow responses with: <META HTTP-EQUIV=Refresh.
HTTP Headers that Servers Send Browsers | ||
---|---|---|
Field | Typical Value | Meaning |
Server: | Apache/2.0.55 (NETWARE) mod_perl/1.99_12 Perl/v5.8.4 | Which server software being used. |
Accept-Ranges: | bytes | Inform the browser that the server supports downloading just parts of files, as small as a byte granularity. |
Location: | http://mindprod.com/index.html | If the URL (Uniform Resource Locator) has been redirected/moved, this is the new URL to use instead. You can tell if it is permanently or temporarily redirected by looking at the response code. |
Keep-Alive: | timeout=15, max=99 | how long to keep this socket open for more messages. |
Connection: | Keep-Alive | requests browser keep the socket open for further messages. |
Content-Type: | image/png | MIME type of the payload from the server. Also used to encode the CharSet encoding, e. g. Content-Type: text/html; charset=utf-8 |
Content-Encoding: | gzip | gzip or x-zip or deflate or not present if no compression. |
Content-disposition: | attachment;filename=smile.png | Server suggests a filename to save this download under. |
Content-Length: | 842 | length in encoded bytes of the payload from the server. |
In the real world, the conversations between browser/client and server are much more complicated as slipshod than you might suppose. Each query often results is a flurry of permanent and temporary redirects back and forth. Each element on an HTML page must be requested independently. Sometimes servers will send back a fail error code, then send the page anyway. Or they will send a 404 with an OK text response code. Sometimes servers refuse HEAD requests, but accept the equivalent GET. Sometimes servers send back https: in response to an http: request. Sometimes servers give you a totally different page from the one you requested and don’t tell you the one you wanted is on longer available. Sometimes servers redirect to localhost, or send back gibberish messages. Sometimes a server won’t send you a page if you have recently previously requested it. They expect you to have cached it. Browsers just do their best to muddle through. When you start emulating browsers with code, you get pretty flaky programs.
In a GET, the parameters are embedded in the URL send to the host, with various header fields following the URL. The first parameter starts with a ?. Subsequent ones start with &. = separates the keyword from the value. Here is what a typical message sent to the server looks like:
A POST, is like a GET, with optional embedded parameters in the URL sent to the host. In addition in has a message tacked on the end after a blank line like this:
Read the response either as bytes (readBytesBlocking) or converted to a String
depending on which protocol you specified e.g. http:, https:, file:, jar:…
IE 5 & 6 had a bug involving javascript and gzip encoding. Microsoft failed to change the User-Agent string after the bug fix and thus the server does not have enough information to determine whether or not the browser is defective.
HTTP is an unnecessarily fluffy and asymmetrical protocol. If I were redesigning it:
RFC 2049 MIME part 2, non ASCII (American Standard Code for Information Interchange).
RFC 1945 HTTP 1.0 specification.
RFC 2045 MIME Part One: Format of Internet Message Bodies, specifies the various headers used to describe the structure of MIME messages.
RFC 2046 MIME Part Two: Media Types, describes the general structure of the MIME media typing system and defines an initial set of media types.
RFC 2047 MIME Part Three: Message Header Extensions for non-ASCII text
RFC 6838 and RFC 4289 MIME Part Four: Registration Procedures
RFC 2049 MIME Part Five: Conformance Criteria and Examples, Provides some illustrative examples of MIME message formats
RFC 2183 MIME Part Five: Conformance Criteria and HTTP Content-Disposition
RFC 7230 updates the HTTP protocol. Details of what all the header fields do.
RFC 2617 (obsolete) replaced by RFC 7235: for details on how to send username and password in http headers to restrict access
RFC 2183 MIME Part Five: Conformance Criteria and HTTP Content-Disposition
HttpsURLConnectionImpl and FileURLConnection are undocumented.
This page is posted |
http://mindprod.com/jgloss/http.html | |
Optional Replicator mirror
|
J:\mindprod\jgloss\http.html | |
Please read the feedback from other visitors,
or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission. | ||
Canadian
Mind
Products
IP:[65.110.21.43] Your face IP:[18.97.9.170] |
| |
Feedback |
You are visitor number | |