| [accepted revision] | [accepted revision] |
Content deleted Content added
m →Example session: (Oh, it already was there. A little repetition is probably good...) |
Group sections into a larger section of related material |
||
Line 249:
The most popular way of establishing an encrypted HTTP connection is [[HTTP Secure]].<ref>{{cite book|last=Canavan|first=John|title=Fundamentals of Networking Security|year=2001|publisher=Artech House|___location=Norwood, MA|isbn=9781580531764|pages=82–83}}</ref> Two other methods for establishing an encrypted HTTP connection also exist: [[Secure Hypertext Transfer Protocol]], and using the [[HTTP/1.1 Upgrade header]] to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.<ref>{{cite web|last1=Zalewski|first1=Michal|title=Browser Security Handbook|url=https://code.google.com/p/browsersec/wiki/Part1#True_URL_schemes|accessdate=30 April 2015}}</ref><ref>{{cite web|title=Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1|url=https://code.google.com/p/chromium/issues/detail?id=4527|accessdate=30 April 2015}}</ref><ref>{{cite web|title=Mozilla Bug 276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1|url=https://bugzilla.mozilla.org/show_bug.cgi?id=276813|accessdate=30 April 2015}}</ref>
== Message Format ==
==Request message==▼
The client and server communicate by sending plain-text ([[ASCII]]) messages. The client sends '''requests''' to the server and the server sends '''responses'''.
▲===Request message===
The request message consists of the following:
Line 261 ⟶ 264:
A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification in RFC 1945.<ref name="apacheweek_com-http11">{{cite web|title=Apache Week. HTTP/1.1|url=http://www.apacheweek.com/features/http11}} 090502 apacheweek.com</ref>
===Response message===
The response message consists of the following:
Line 271 ⟶ 274:
The status line and other header fields must all end with <CR><LF>. The empty line must consist of only <CR><LF> and no other [[Whitespace (computer science)|whitespace]].<ref name="ietf2616sec4" /> This strict requirement for <CR><LF> is relaxed somewhat within message bodies for consistent use of other system linebreaks such as <CR> or <LF> alone.<ref>{{cite IETF|rfc=2616|sectionname=Canonicalization and Text Defaults|section=3.7.1|idanchor=ietf}}</ref>
===Example session===
Below is a sample conversation between an HTTP client and an HTTP server running on [[example.com|www.example.com]], port 80. As mentioned in the previous sections, all the data is sent in a plain-text ([[ASCII]]) encoding, using a [[Newline|two-byte CR LF]] ('\r\n') line ending at the end of each line.
====Client request====
<source lang="http">
GET /index.html HTTP/1.1
Line 282 ⟶ 285:
A client request (consisting in this case of the request line and only one header field) is followed by a blank line, so that the request ends with a double newline, each in the form of a [[carriage return]] followed by a [[line feed]]. The "Host" field distinguishes between various [[Domain Name System|DNS]] names sharing a single [[IP address]], allowing name-based [[virtual hosting]]. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
====Server response====
<source lang="http">
HTTP/1.1 200 OK
| |||