UserAgent.html
7.11 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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
<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>
-- Axioms of Web architecture
</title>
<link rel="Stylesheet" href="di.css" type="text/css" />
<meta http-equiv="Content-Type" content="text/html" />
</head>
<body bgcolor="#DDFFDD" text="#000000">
<address>
Tim Berners-Lee<br />
Date: 1998, last change: $Date: 2009/08/27 21:38:10 $<br />
Status: personal view only. Editing status: first draft.
</address>
<p>
<a href="./">Up to Design Issues</a>
</p>
<h3>
Axioms of Web Architecture: n
</h3>
<hr />
<h1>
User Agent watch points
</h1>
<p>
Interpreting HTTP
</p>
<p>
Browsers and Email programs are user agents. This isn't just
a formal long term for them, it is an important issue. They
are programs which act on behalf of, and represent, the user.
</p>
<p>
The computer protocols such as HTTP are defined to carry a
particular meaning, and it behooves a user agent to
representthat meaning to the user, or the whol system of
peeople and machines breaks.
</p>
<p>
Here are a few ways in which browser designs should and often
have not lived up to this.
</p>
<h3>
Distinguish between HTTP "301 Moved permanently" and "302
Found"
</h3>
<p>
There are two forms of redirection in HTTP. Each gives a new
place to look for a resource, but for completely different
reasons.
</p>
<p>
"<a href=
"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2">301
Moved</a>" is a response which indicates that the server has
committed the unthinkable and for some reason not in a
position to serve the document at that URI. It indicates that
all references to the original should be change to the new
one, including bookmarks and document links. This is an
expensive solutin to a serious problem. It does not, of
course, work completely, but it is the HTTP way for a server
to alert a client of this situation.
</p>
<p>
"<a href=
"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3">302
Found</a>" is a response which indicates that the server is
working as a name server. It is a success result indicating
that you asked for a good document, and that the actual
contents can curently be found at the given URI.
</p>
<p>
The imporant use of name server functionality is when for
some reason it is impractical to server the document directly
from a server which can hold the persistent URI.. For
example, a university might issue definitive URIs for its
successful theses, and might have a very reliable, stable,
low bandwidth machine which handles that URI space. However
the content of the theses might in practice be delivered by
fast machines located in the departments. The university may
make a persistence commitment for the original URI but not
for the department's server. Similarly, a user may for load
reasons or speed reasons be directed to a mirror.
</p>
<p>
It is important that when a user agent follows a "Found" link
that the user does not refer to the second (less persistenet)
URI. Whether copying down the URI from a window at the top of
a doucment, or making a link to the document, or bookmarking
it, the reference should (except in very special cases) be to
the original URI.
</p>
<p>
Very few browsers (Mozilla? Amaya>) implement this
properly as of 1999.
</p>
<p>
There is also <a href=
"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8">
307 temporary redirect</a>, which is similar to a 302 Found.
</p>
<p>
See also:
</p>
<ul>
<li>
<a href="http://www.w3.org/Provider/Style/URI.html">Cool
URIs don't change</a> (In the Style Guide for Online
Hypertext)
</li>
</ul>
<h3>
Distinguish between an HTTP <em>POST</em> and a <em>GET</em>
</h3>
<p>
GET operations (as happen when you follow a regular hypertext
link) are fundamentally different from POST operations (as
happen when you submit a form to order a book), The first is
reversible, has no long term effect, cannot comit a user to
anything. The latter does committhe user.
</p>
<p>
A graphic client, for example, should use a very different
<strong>cursor</strong> while the user is hovering over a
POST button to when the user is hovering over a GET link.
</p>
<p>
Doing a POST is like sending an email. (Currently 1999 it may
be more secure because it will often happen over an https
secure connection while many email clients do not encrypt
messages.) It is really important to be able to find a list
of the emails you have sent: these are the things you are
committed to. The same applies to HTTP POST forms. The web
client should <strong>keep a record</strong> of POSTs which
have been submitted.
</p>
<p>
This would of course waste a lot of space for those web sites
which get GET and POST muddled, but they are fundmentally
broken anyway and the sooner we just fix this misuse on all
sides the better. In the future, digital signature will be an
action just like POST, but with weight added and the user
awareness of the choice of key. Understanding when a
commitment is made is a really important part of the user
interface. Get it right.
</p>
<p>
See also:
</p>
<ul>
<li>
<a href="Axioms.html#get">Axioms: HTTP GET if and only if
no side effects</a>
</li>
<li>
<a href="/Protocols/rfc2616/rfc2616.html">HTTP
specification</a>
</li>
</ul>
<h2>
Hide URIs
</h2>
<p>
Objective: A web user should never be aware of a URI while
using the Web, either creatively or browsing.
</p>
<h4>
Techniques:
</h4>
<ul>
<li>Hide all access to URIs inside special "under the hood"
windows or status bars;
</li>
<li>Use titles to identify resources;
</li>
<li>Introduce RDF properties to indicate short titles and
icons to make this easier;
</li>
<li>Remove all URI-aware functions to a special (optional)
menu;
</li>
<li>Allow files for upload, or other documents to be
referenced by drag-and-drop, or copy referemce/link to
clipped
</li>
</ul>
<p>
Web <strong>servers</strong> have to help by generating URIs
for new documents. A new document creation form should
redirect the user to a document whose UIRI has bene
generatde, and which the user can then edit.
</p>
<hr />
<p>
<a href="Overview.html">Up to Design Issues</a>
</p>
<p>
<a href="../People/Berners-Lee">Tim BL</a>
</p>
</body>
</html>