Julian Reschke | 1 Jun 14:50 2008
Picon
Picon

Re: 100-continue implementation status question


Julian Reschke wrote:
> 
> Paul Leach wrote:
>>
>>
>> Can people help with the following question:
>>
>> How widely implemented is 100-continue? And how correctly?
>> ...
> 
> In Java servlet world: the servers do implement it partly.
> 
> That is, they understand Expect: 100-continue, and reply with 100 
> Continue when asked for it.
> 
> However, the containers do not let the servlets have a say (inspecting 
> the request, and potentially saying "417 Expectation Failed"). This is a 
> restriction that has been known for a long time, and I certainly hope 
> the Java Servlet EG will address that at some point of time (I haven't 
> checked recently, so maybe they already did and I missed it).

Speaking of which... does anybody know whether the Servlet EG is 
following this mailing list?

BR, Julian

Mark Nottingham | 2 Jun 05:24 2008
Picon

Re: 100-continue implementation status question


I've fired off a message.

On 01/06/2008, at 10:50 PM, Julian Reschke wrote:

>
> Julian Reschke wrote:
>> Paul Leach wrote:
>>>
>>>
>>> Can people help with the following question:
>>>
>>> How widely implemented is 100-continue? And how correctly?
>>> ...
>> In Java servlet world: the servers do implement it partly.
>> That is, they understand Expect: 100-continue, and reply with 100  
>> Continue when asked for it.
>> However, the containers do not let the servlets have a say  
>> (inspecting the request, and potentially saying "417 Expectation  
>> Failed"). This is a restriction that has been known for a long  
>> time, and I certainly hope the Java Servlet EG will address that at  
>> some point of time (I haven't checked recently, so maybe they  
>> already did and I missed it).
>
> Speaking of which... does anybody know whether the Servlet EG is  
> following this mailing list?
>
> BR, Julian
>

(Continue reading)

Mark Nottingham | 2 Jun 06:40 2008
Picon

Re: Resolve issue 98?


I agree that the original sentence:
> A server that does not support such an extension MAY discard the  
> request body.
was nonsense, but it would be helpful to spell out what a server  
should do if it doesn't support such an extension.

E.g.,

"""An origin server (or proxy server, if Max-Forwards is 0) that does  
not support such an extension SHOULD respond with 415 Unsupported  
Media Type."""

Although, given the sentence we're talking about taking out, this may  
be closer to the original intent:

"""An origin server (or proxy server, if Max-Forwards is 0) that does  
not support such an extension MAY ignore the request body."""

On 31/05/2008, at 1:04 AM, Julian Reschke wrote:

>
> Hi,
>
> I'd like to resolve issue 98 (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/98 
> >, "OPTIONS request body) soon.
>
> The proposed change
(<http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/98/i98.diff 
> >) follows Roy's advice that the sentence in question ("A server  
(Continue reading)

Yves Lafon | 2 Jun 09:10 2008
Picon

Re: i28 proposed replacement text


On Wed, 28 May 2008, Henrik Nordstrom wrote:

> On ons, 2008-05-28 at 10:41 -0400, Yves Lafon wrote:
>
>> Then we must at least say that the encoding used (not chunked) must
>> give the same characteristics as chunked wrt detection of the end of the
>> message.
>
> Why? The protocol will not fall down if a message is unexpectedly cut
> short.

Essentially for what it below, the need to verify the integrity of the 
message. It is needed when you don't cut the connection, but it is a 
desirable property even if the connection is cut, to detect an error case 
(like cutting the connection in the middle of a chunked stream) from a 
normal response.

> A note mentioning that this may downgrade the message integrity to the
> level of a Connection: close without Content-Length message may be
> acceptable, but not a must. In practice most file formats and encodings
> easily detect truncation.

partial or absolute detection ? If the format allows multiple concatenated 
entries, and integrity check is true if you reach exactly the end of one 
entry, you have a highly probable integrity check but not an absolute one.

In any case, a note explaining that it might be difficult to figure out 
the integrity of the message in this case would be sufficient.

(Continue reading)

Julian Reschke | 2 Jun 09:15 2008
Picon
Picon

Re: Resolve issue 98?


Mark Nottingham wrote:
> 
> I agree that the original sentence:
>> A server that does not support such an extension MAY discard the 
>> request body.
> was nonsense, but it would be helpful to spell out what a server should 
> do if it doesn't support such an extension.
> 
> E.g.,
> 
> """An origin server (or proxy server, if Max-Forwards is 0) that does 
> not support such an extension SHOULD respond with 415 Unsupported Media 
> Type."""
> 
> Although, given the sentence we're talking about taking out, this may be 
> closer to the original intent:
> 
> """An origin server (or proxy server, if Max-Forwards is 0) that does 
> not support such an extension MAY ignore the request body."""

Both are plausible answers.

It seems that the only thing we can require a server to do is to be 
robust. So either reject the request or ignore the request body.

Of course that makes it tricky to actually *use* a request body in new 
protocols. WebDAV DeltaV solves this by allowing the client to find out 
whether the server understood the request body (see, for instance, 
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.5>).
(Continue reading)

Henrik Nordstrom | 2 Jun 10:33 2008
Picon

Re: i28 proposed replacement text


mån 2008-06-02 klockan 03:10 -0400 skrev Yves Lafon:

> Essentially for what it below, the need to verify the integrity of the 
> message.

Which in HTTP is provided by Content-MD5 (even if partly misunderstood
on 206 responses), or by Digest qop=auth-int (if implemented by
anyone..)

> It is needed when you don't cut the connection, but it is a 
> desirable property even if the connection is cut, to detect an error case 
> (like cutting the connection in the middle of a chunked stream) from a 
> normal response.

Sure, there is many things which is desireable and nice, but it doesn't
make them MUSTs..

> partial or absolute detection ? If the format allows multiple concatenated 
> entries, and integrity check is true if you reach exactly the end of one 
> entry, you have a highly probable integrity check but not an absolute one.

You don't hav an absolute one even if Content-Length matches or chunked
encoding is terminated proper. It all depends on where the failure was
and how communication was to that.. In any situation where there may be
some form or proxy inbetween (including servers running scripts) both
Content-Length and chunking is synthetic and hop-by-hop. As recipient
you can only be absolutely sure that if there is a mismatch then
something is wrong..

(Continue reading)

Henrik Nordstrom | 2 Jun 12:31 2008
Picon

Re: Struggling with LWS (2616) vs LWSP (2831bis)

On tis, 2008-05-27 at 11:46 +0200, Julian Reschke wrote:

> For now, I'm just trying to make progress on the ABNF conversion; *not* 
> on changing the allowed syntax (for which I think we don't have 
> consensus yet).

I am in favor of splitting the BNF in "recommended" and "obsolete"
syntax, just done for MIME.

Any change which lines up HTTP BNF with MIME BNF will also have an
automatic +1 from me. There is a lot gained if the community can stick
to a as common syntax as possible.

Just as for MIME the silly constructs is where most parsing interop
issues is seen. There is many implementations which do fail on empty
list members, excessive line folding (or folding at all), incorrectly
placed CR characters etc.

There is a lot fewer implementations that rely on such features, and the
very few I have seen so far using "silly" construct has been mostly
caused bugs and not intentional constructs and where folding or empty
list elements rules accidently makes the message still valid..

Regards
Henrik
Jamie Lokier | 2 Jun 12:31 2008

Re: i28 proposed replacement text


Yves Lafon wrote:
> >As already mentioned both gzip and deflate has this property to a
> >sufficient level.
> 
> But it is used that way in deployed servers/clients ? Or is chunked 
> encoding always the norm.

Chunked encoding clearly is not the norm when sending compressed
dynamic content to a HTTP/1.0 client.

-- Jamie

Jamie Lokier | 2 Jun 12:35 2008

Re: i28 proposed replacement text


Henrik Nordstrom wrote:
> > partial or absolute detection ? If the format allows multiple concatenated 
> > entries, and integrity check is true if you reach exactly the end of one 
> > entry, you have a highly probable integrity check but not an absolute one.
> 
> You don't hav an absolute one even if Content-Length matches or chunked
> encoding is terminated proper. It all depends on where the failure was
> and how communication was to that..

Agree, except we can at least identify when it's not the protocol
itself introducing undetected failure.

> In any situation where there may be
> some form or proxy inbetween (including servers running scripts) both
> Content-Length and chunking is synthetic and hop-by-hop. As recipient
> you can only be absolutely sure that if there is a mismatch then
> something is wrong..

According to RFC2616, Content-Length is an entity header and an
end-to-end header, therefore should not be synthesised hop-by-hop.
Yeah, I know :-)

-- Jamie

Henrik Nordstrom | 2 Jun 12:43 2008
Picon

Re: Basic Authentication and encoding of non-ASCII characters in credentials

On ons, 2008-05-28 at 10:51 +0200, Julian Reschke wrote:

> I would like Basic Auth to use UTF-8. But: this has been discussed again 
> and again of the last years, and I think we haven't come to a consensus 
> that it *can* be changed.

On that issue it's a question of who to break.. But most implementations
do use ISO-8859-1 for basic, and fail on characters outside that set.

There is a easy path forward on that and it's to specify a Basic2 scheme
addressing these concerns. Trying to solve the existing Basic scheme is
a dead end as the syntax does not allow changes or extensions. The only
available option is by adding a new header, and one may then just as
well use a different scheme with better syntax.

> For instance, I know by first hand of people in Europe relying that 
> (non-ASCII) ISO-8859-1 characters in credentials work in Basic 
> Authentication, and the clients and servers these people depend on use 
> ISO-8859-1 as encoding.

Yes.

> Choosing different encodings in the same UA depending who generated the 
> HTTP request is just bizarre, and will not help solving the problem.

Fully agreed.

> It seems an easy way to make progress would be to define "Basic2" (using 
> UTF-8), and try to get it supported in the open source browser engines 
> (FF/Webkit) and Apache httpd.
(Continue reading)


Gmane