common user-agent problems: some thoughts

http://www.w3.org/TR/cuap

1.8 Provide a mechanism to allow authentication information to expire.

<quote> ... They should also allow users to "flush" that
authentication information on request. ... </quote>

ideally on a per-site or per-domain basis (e.g., as for your indicated
example, forget my bank password but remember my slashdot posting
passwords)

1.10 Allow the user to keep track of completed HTTP POST requests.

<rant> and think carefully about how cacheing (by the user agent, as
opposed to proxies) relates to this - user agents provide for backwards
and forwards movement along the time-line; going `Back' to a page
obtained by a POST is particularly contentious.  Such pages are commonly
not cached `because of security implications', yet the user is asked on
trying to go Back to one `shall I re-POST the form data'.  Remembering
the form data contains all the security implications of cacheing the
form's output; while expecting the user to have any idea what data is
about to be re-POSTed is ridiculous.  They're coming Back to the page,
possibly after a long digression in one of many windows.  Further,
re-POSTing the data may have serious consequences - e.g. purchasing
another copy of the book; worse yet, with the growth of e-commerce,
purchasing everything *now* in your cookie-carried shopping cart, which
the original form may have displayed for you to confirm but the Back
route certainly does not. </rant>

Any history menu that lets one go back or forward several steps (a nice
feature, IMO) should also make clear which entries in the menu are the
results of POST operations, at least unless the results are cached so as
to avoid any of the issues above.

1.13 Use the user interface language as the default value for language
  negotiation.

and, just because Apache and Zeus are very considerate about q-less
preferences, doesn't mean you should just assume web servers will `do
what you meant' with a header that just lists the languages, in
decreasing order of welcomeness. <sigh>

2.2 Respect media descriptors when applying style sheets.

In your list of media descriptor examples, perhaps the most obvious
ommitted example is: printer

3.6 List only supported media types in an HTTP Accept header.

this section should address its superficial inconsistency with

1.3 Allow the user to retrieve Web resources even if the browser
  cannot render them.

i.e.: IIRC the content-negotiation allows for retrieval of a resource
by explicit URI regardless of the content-type thus returned being in
conflict with the Accept headers; but 3.6 could be mis-construed.

4.1 Handle the fragment identifier of a URI when the HTTP request is
  redirected.

<quote> If URI2 already has a fragment identifier, then #frag must not
be appended and the new target is URI2. </quote>

Interesting.  I would have thought that:

  if I intend to display foo#hello but
  my request for foo gets redirected to bar#foo,
  I should display bar#hello.

I'm imagining, here, that foo is one of several pages amalgamated into
bar, with #foo being the fragment identifier for where foo's part
begins; at least when bar has a #hello slightly beyond its #foo, I
clearly want #hello.  If the amalgamation has mangled the fragment
identifier to #hello-foo or #foo.hello, I shouldn't guess: it's time
for the user agent to tell its boss - the user - what's going on and
ask for directions.  That, at least, involves mentioning the redirect
and both fragment identifiers involved in it; it should also involve
access to a list of fragment identfiers in bar, ideally promoting
(i.e. putting at the top of the list, or high-lighting within a list
by order within bar) identifiers containing the texts `foo' and
`hello'.  Real intelligence's handling of this will degrade more
gracefully in the face of surprises than any heuristic ...

	Eddy.
--
speaking for myself, not on anyone's behalf.
Not even my employer's

Received on Friday, 17 May 2002 02:51:16 UTC