ProtocolVersions.html
5.74 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
<title>
ProtocolVersions -- Design Issues
</title>
<nextid />
</head>
<body>
<a href="OldDocs.html"><img src="../Icons/WWW/arch1990" /></a>
<hr />
<address>
(part of <a name="10" href=
"../Implementation/DesignNotes.html">Design Notes</a> )
92.06.11 RC
</address>
<h1>
From Version to Version of HTTP
</h1>
<h2>
Current version of HTTP
</h2>I propose 0.9 as the number of the <a name="3" href=
"HTTP0.9Summary.html">current version</a> .
<h2>
Compatibility
</h2>Today (June 1992) WWW is used in a community of highly
computer literate people. The cost of making all users adopt a
new, incompatible version of the browser and/or the server is
not very high, neither in effort nor in inconvenience.
<p>
Nevertheless, I will propose to go to a new version in a
compatible way. [Absolutely -- we can require complete
back-compatibility for both clients and servers - Tim]
</p>
<h2>
Imperatives
</h2>Browsers and servers must have a few <a name="8" href=
"HTTP0.9Summary.html#1">characteristics</a> that must be kept
over all versions.
<h2>
What has a version?
</h2>A version is associated with the HTTP protocol used in the
exchange between servers and browsers. Because two agents on
two different machines are involved, there can be two different
implementations of the protocol at work. The version of the
browser or the server refers to its capabilities in displaying
or providing, not to the protocol. Perhaps a Browser or server
should be characterised by both numbers: Linemode 3.4/2.0 would
mean browser version 3.4 using HTTP 2.0. [Hang on -- let's not
complicate things unduly. The software has a version number,
and so does the protocol but they're nothing to do with each
other]
<p>
An HTTP version number consists of
</p>
<ul>
<li>an integer indicating the set of features,
</li>
<li>a dot,
</li>
<li>an integer indicating the level, whereby the differences
between, say, 2.01 and 2.02 must be such that ANY two version
2 implementations must be able to communicate without
problems.
</li>
</ul>[So you require back-compatibility between "major"
versions number before the dot changing] and both-ways
compatibility between "minor" versions? -- DEC jargon]
<h2>
Aims
</h2>In a new version of HTTP, there can be added features, but
there can also be a lack of deprecated ones. Communication
between a browser using version n and a server using version m
should in some sense be possible.
<p>
It is reasonable to require that an agent using version n+1
also still knows how to handle version n but does not have to
know version n-1.
</p>
<h2>
Forwards
</h2>There are three disjoint elements:
<ul>
<li>the WWW data model, which today consists of documents
which may have explicit links and/or be queryable with
text-based queries. [Was: maybe I'd prefer to call data
bases, since an index is a reference table built from a data
base to ease access to it)." An index can be many <a name="9"
href="WhatIsAnIndex.html">things</a> ] There is no reason
why other types should not be added, such as
time-indefinite communications (eg. a telnet session, TV or
process control).[Is this really different from a
document?]
</li>
<li>the HTTP protocol, which should be defined outside the
document contents. It needs to evolve and expand.
</li>
<li>the HTML markup which is today the only implemented
format we accept for the document contents. Here certainly we
want more.
</li>
</ul>The next releases should distinguish these cleanly. One
way is to talk HTTP over a control connection and documents
over a data connection.
<h2>
Pragmatism
</h2>Having suggested a split of control and data, I realise
that at present this is too much, and so we must keep going on
one connection. [Ample justification for this is the difference
in reponse time from HTTP servers and FTP servers -- the latter
using 2 connections] That implies though that we must do our
own transmission protocol inside HTTP, ie. when we send, say,
binary data, then because we mix HTTP and data on the same
connection, we have to do things inside HTTP like "here follows
3406 bytes of binary data" because otherwise we are not
guaranteed to be able to distinguish between HTTP controls and
document data.
<h2>
Proposed modifications
</h2>
<h3>
Version 1.0:
</h3>The HTTP version number is sent in every communication, by
the browser after the argument to GET, by the server in a tag
at the start. [I don't see the reason for this version.]
<h3>
Version 2.0:
</h3>The HTTP version number is sent at the start of every
communication.
<p>
The HTTP commands are not in HTML; however, they are mixed in
with the data stream. [I would say they envelop the data
stream. I think it is important to keep the TOEOF style as an
option because it is so practical]
</p>
<p>
See also <a name="4" href="ProtocolProblems.html">problems to
solve</a> , a way of communicating <a name="6" href=
"Protocolcomms.html">with different versions</a> and a
<a name="7" href="CompatibleProof.html">proof</a> that the
new version is backwards compatible.
</p>
</body>
</html>