W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: TICKET 259: 'treat as invalid' not defined

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Sun, 7 Nov 2010 15:10:56 -0700
To: Adam Barth <ietf@adambarth.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>
Message-Id: <20101107151056.7d473a86.eric@bisonsystems.net>
Adam Barth wrote:
>
> Julian Reschke wrote:
> >
> >> 1) Many servers send invalid messages to user agents.
> >
> > No data was provided that this is indeed the case for C-D.
> 
> No data was provided that this isn't the case.  Given that we see
> invalid message everywhere else, common sense tells us that we will
> see invalid messages here too.
> 

Plus, invalid instances of headers which aren't even defined by HTTP.
Instead of spreading this concern out and imposing a new requirement on
authors of such headers (first, seek browser-vendor approval of error-
correction language, which as Julian mentioned may result in decreased
participation if such authors simply ignore IETF standardization), it
would seem that common sense tells us that defining error correction
behavior for user-agents will always exceed the scope of HTTP.

> 
> In that case, perhaps we should make including the % character invalid
> as the results are not predictable from the point of view of servers.
> 

The API I'm developing (which I've mentioned on rest-discuss, this isn't
a hypothetical) works as follows:  user-agent dereferences a resource,
the response representation contains form code which instructs the user-
agent how to PUT a local file to a server-defined URI, preserving the
filename of the local resource in Content-Disposition.  If the local
filesystem allows spaces, for example, they're percent-encoded because
the target filesystem does not allow spaces.  Expressing the sender
intent requires a protocol mechanism which allows '%' without dictating
that it must be decoded.  From the POV of my server, the results are
completely predictable, because it isn't the sender in this case; and
has exactly zero interoperability issues.  I would prefer my API not to
be deprecated based on an issue that doesn't even affect it.

-Eric
Received on Sunday, 7 November 2010 22:11:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT