You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
203 lines
7.1 KiB
203 lines
7.1 KiB
<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>
|