Mark Nottingham | 1 Jul 2011 05:52
Favicon
Gravatar

Re: status code for header fields to big

Personally - I think 413 is good for this; the response body and/or headers can fine-tune as to why it was
rejected (as with any other error response).

Recall that we've already tuned the definition of 413 to say 

   The server is refusing to process a request because the request
   representation is larger than the server is willing or able to
   process.

note 'representation' -- which includes headers.

Cheers,

On 30/06/2011, at 10:46 PM, Julian Reschke wrote:

> Hi,
> 
> I quickly ran some tests, and the results are (with what I suppose are the default settings):
> 
> Apache-Coyote/1.1 (Tomcat):
> 
> Limit for a single header field: ~8000
> Limit for all fields: ~8000
> Status Code: 400
> 
> Apache/2.2.14:
> 
> Limit for a single header field: ~8180
> Limit for all fields: > 16000
> Status Code: 400
(Continue reading)

Julian Reschke | 1 Jul 2011 16:18
Picon
Picon

Re: status code for header fields to big

On 2011-07-01 05:52, Mark Nottingham wrote:
> Personally - I think 413 is good for this; the response body and/or headers can fine-tune as to why it was
rejected (as with any other error response).

I'm not totally convinced; maybe we can treat this as a separate issue 
("expand scope of 413"?), and make progress on #282 independently of it?

> Recall that we've already tuned the definition of 413 to say
>
>     The server is refusing to process a request because the request
>     representation is larger than the server is willing or able to
>     process.
>
> note 'representation' -- which includes headers.

"Entity", as used in 2616, included the headers as well; so this was 
just a terminology update, right?

Best regards, Julian

Julian Reschke | 1 Jul 2011 18:51
Picon
Picon

#299: status code for header fields to big

On 2011-07-01 16:18, Julian Reschke wrote:
> On 2011-07-01 05:52, Mark Nottingham wrote:
>> Personally - I think 413 is good for this; the response body and/or
>> headers can fine-tune as to why it was rejected (as with any other
>> error response).
>
> I'm not totally convinced; maybe we can treat this as a separate issue
> ("expand scope of 413"?), and make progress on #282 independently of it?
>
>> Recall that we've already tuned the definition of 413 to say
>>
>> The server is refusing to process a request because the request
>> representation is larger than the server is willing or able to
>> process.
>>
>> note 'representation' -- which includes headers.
>
> "Entity", as used in 2616, included the headers as well; so this was
> just a terminology update, right?
>
> Best regards, Julian

I have opened <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/299> 
for this question.

Best regards, Julian

Peter Saint-Andre | 2 Dec 2011 22:36
Favicon

Re: status code for header fields to big

I notice that 413 didn't end up in draft-nottingham-http-new-status
(although it does have "431 Request Header Fields Too Large"). Where did
we end up on this one?

On 6/30/11 9:52 PM, Mark Nottingham wrote:
> Personally - I think 413 is good for this; the response body and/or headers can fine-tune as to why it was
rejected (as with any other error response).
> 
> Recall that we've already tuned the definition of 413 to say 
> 
>    The server is refusing to process a request because the request
>    representation is larger than the server is willing or able to
>    process.
> 
> note 'representation' -- which includes headers.
> 
> Cheers,
> 
> 
> On 30/06/2011, at 10:46 PM, Julian Reschke wrote:
> 
>> Hi,
>>
>> I quickly ran some tests, and the results are (with what I suppose are the default settings):
>>
>> Apache-Coyote/1.1 (Tomcat):
>>
>> Limit for a single header field: ~8000
>> Limit for all fields: ~8000
>> Status Code: 400
(Continue reading)

Julian Reschke | 2 Dec 2011 23:06
Picon
Picon

Re: status code for header fields to big

On 2011-12-02 22:36, Peter Saint-Andre wrote:
> I notice that 413 didn't end up in draft-nottingham-http-new-status

413 already exists ("Request Entity Too Large"); we thought about 
extending it to cover this case (and did with 
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/255) but then decided 
that a new code makes more sense. (So the change for ticket #255 will be 
backed out once we know 431 goes ahead).

Any while I type this I see you updated the ticket :-)

> (although it does have "431 Request Header Fields Too Large"). Where did
> we end up on this one?
> ...

The definition of 413 will be reverted back to what it said before 
change <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1310>.

Best regards, Julian

Peter Saint-Andre | 2 Dec 2011 23:08
Favicon

Re: status code for header fields to big

On 12/2/11 3:06 PM, Julian Reschke wrote:
> On 2011-12-02 22:36, Peter Saint-Andre wrote:
>> I notice that 413 didn't end up in draft-nottingham-http-new-status
> 
> 413 already exists ("Request Entity Too Large"); we thought about
> extending it to cover this case (and did with
> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/255) but then decided
> that a new code makes more sense. (So the change for ticket #255 will be
> backed out once we know 431 goes ahead).
> 
> Any while I type this I see you updated the ticket :-)
> 
>> (although it does have "431 Request Header Fields Too Large"). Where did
>> we end up on this one?
>> ...
> 
> The definition of 413 will be reverted back to what it said before
> change <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1310>.

Thanks for the clarifications.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

Julian Reschke | 2 Dec 2011 23:21
Picon
Picon

Re: status code for header fields to big

On 2011-12-02 23:06, Julian Reschke wrote:
> ...
>> (although it does have "431 Request Header Fields Too Large"). Where did
>> we end up on this one?
>> ...
>
> The definition of 413 will be reverted back to what it said before
> change <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1310>.
> ...

Sorry, me confused about two different headers.

We did not change 413, as 431 was on the table.

We *did* extend 503, and this can be backed out if we get 429.

Best regards, Julian

Peter Saint-Andre | 2 Dec 2011 23:26
Favicon

Re: status code for header fields to big

On 12/2/11 3:21 PM, Julian Reschke wrote:
> On 2011-12-02 23:06, Julian Reschke wrote:
>> ...
>>> (although it does have "431 Request Header Fields Too Large"). Where did
>>> we end up on this one?
>>> ...
>>
>> The definition of 413 will be reverted back to what it said before
>> change <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1310>.
>> ...
> 
> Sorry, me confused about two different headers.
> 
> We did not change 413, as 431 was on the table.
> 
> We *did* extend 503, and this can be backed out if we get 429.

You'll get it. I plan to start the IETF Last Call in the next few days.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

Julian Reschke | 3 Dec 2011 10:08
Picon
Picon

Re: status code for header fields to big

On 2011-12-02 23:21, Julian Reschke wrote:
> ...
> Sorry, me confused about two different headers.
>
> We did not change 413, as 431 was on the table.
>
> We *did* extend 503, and this can be backed out if we get 429.
> ...

Proposed change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/255/255.diff>

Mark Nottingham | 5 Dec 2011 02:02
Favicon
Gravatar

Re: status code for header fields to big

Can we leave the reference to the retry-after header def (line 2282)?

Cheers,

On 03/12/2011, at 8:08 PM, Julian Reschke wrote:

> On 2011-12-02 23:21, Julian Reschke wrote:
>> ...
>> Sorry, me confused about two different headers.
>> 
>> We did not change 413, as 431 was on the table.
>> 
>> We *did* extend 503, and this can be backed out if we get 429.
>> ...
> 
> Proposed change: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/255/255.diff>

--
Mark Nottingham   http://www.mnot.net/

Julian Reschke | 5 Dec 2011 10:50
Picon
Picon

Re: status code for header fields to big

On 2011-12-05 02:02, Mark Nottingham wrote:
> Can we leave the reference to the retry-after header def (line 2282)?
> ...

Done. See <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1486>.

Best regards, Julian


Gmane