Subject: #282: Recommend minimum sizes for protocol elements

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Jun 2011 10:58:28 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/282>

Combined proposal:

For HTTP headers, insert at end of p1 3.2:

"""
HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server MUST be prepared to receive request headers of unbounded length and respond with the 413 (Request Entity Too Large) status code if the received header(s) would be longer than the server wishes to handle (see Section 8.4.14 of [Part2]).

A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.

Various ad-hoc limitations on header length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support messages whose combined headers have 20,000 or more octets.
"""

For max-age and other cache-control directives, move the definition of delta-seconds from Age to a new subsection of p6 1.4 Syntax Notation:

"""
1.4.x Delta Seconds

The delta-seconds rule specifies a non-negative integer, representing time in seconds.

delta-seconds = 1*DIGIT

If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, it MUST consider the value to be 2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD use an arithmetic type of at least 31 bits of range, and senders MUST NOT send delta-seconds with a value greater than 2147483648.
"""

For other situations, add section to p1 Security Considerations:

"""
11.5 Protocol Element Size Overflows

Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform a Denial of Service against implementations that accept fields with unlimited lengths.

To promote interoperability, this specification makes specific recommendations for size limits on request-targets [ref] and blocks of header fields [ref]. These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.

This specification also provides a way for servers to reject messages that have request-targets that are too long [ref] or request entities that are too large [ref].

Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) SHOULD be limited by implementations carefully, so as to not impede interoperability.
"""

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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Jun 2011 08:00:21 +0200

Hi Mark,

> Various ad-hoc limitations on header length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support messages whose combined headers have 20,000 or more octets.

As we discussed one month ago on this subject, shouldn't we recommend even
smaller sizes ? Developers who will find it normal to fill the 20kB with
cookies will create totally unusable applications. The case I observed with
7kB of headers due to a buggy application making a cookie header repeat
itself was perfectly unusable from the net. Common web sites have something
like 80 objects per page on average nowadays, which means that you have to
*upload* 1.6 MB of headers to fetch the whole page at 20kB/headers. On my
ADSL line (1024/256), this takes 50 seconds of saturated uplink bandwidth.
On an HSDPA 3G connection with 64kbps uplink, it takes 200 seconds, or 3m20
to retrieve the whole page.

I'm insisting a bit on this because in the past, all ugliness I observed
could be stopped because of interoperability issues. Developers storing
all the browsing history of the user in a cookie had to stop doing so
because an Alteon LB could not parse requests that did not fit in the
first 1500 bytes for instance. Finally they fixed their application to
store that large amount of data in the app-side session storage. If at
this time they'd have seen the 20kB suggest, they would have stood on
their positions, declaring the Alteon faulty.

>From my experience, 4kB of headers+request is already a lot and extremely
rare. As Poul-Henning reported it, there are cases with much larger values
on some internal networks, but that does not really count, since we can
observe much more ugly specificities on internal enterprise networks (after
all that's where IE6 still lives and where connection-based auth can be met).

And for having used haproxy at 7kB for 7-8 years now, the only handful
situations where it was not enough were due to application bugs that would
not fit in the 20kB limit either.

So whatever we can do not to encourage ugliness should be done, and I think
that suggesting 4kB would be much more net-friendly.

Thanks,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Jun 2011 16:14:12 +1000

> to retrieve the whole page.

Please re-read the text; it's not recommending that people create large headers, but instead that implementers who choose to impose limits in their implementations do so consistently, with a floor.

> their positions, declaring the Alteon faulty.

I'd argue that Alteon is faulty for requiring requests to fit in 1500 bytes. I'm not saying that requests should be that big, but the fact is that on the Web today, they very often are, and implementations that impose limits at that point *will* cause interop problems.

> all that's where IE6 still lives and where connection-based auth can be met).

My experience is that 10K is common in requests and responses; i.e., you don't see it in every site, but if you run a forward proxy, you'll see it every day.

> that suggesting 4kB would be much more net-friendly.

OK, that's a suggestion; what do other folks think?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 22 Jun 2011 06:23:08 +0000

In message <[email-masked]>, Willy Tarreau writes:

>smaller sizes ?

I agree for four reasons:

1. Storing information in cookies are by definition unsafe and a
   privacy problem.  Cookies should primarily be used for anonymous
   nonces which index server side storage.

2. Transmission and bandwidth waste.

3. Cookies represent inverse economics:  It's the webserver which
   controls their size, but the client pays for the bandwidth.

4. This is not a cookie:

   http://forums.techarena.in/off-topic-chat/1055039.htm

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Jun 2011 16:23:54 +1000

Again -- this is NOT recommending how large people should make cookies, but recommending a floor for implementations to support, to improve interop.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 22 Jun 2011 06:35:21 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Again -- this is NOT recommending how large people should make cookies, 
>but recommending a floor for implementations to support, to improve 
>interop.

I agree, but the floor should not be set punishingly high to cater
for clueless people.

Standards should promote interoperability, not stupid behaviour.

Poul-Henning

---

From: Brian Pane <[email-masked]>
Date: Tue, 21 Jun 2011 23:51:17 -0700

> On 22/06/2011, at 4:00 PM, Willy Tarreau wrote:
[...]
> OK, that's a suggestion; what do other folks think?

I'm not sure that 4KB is much better than 20KB.  Here's my rationale...

For a proxy, I tend to think of the per-connection memory usage as:

       client-side TCP receive window
    + client-side TCP send window
    + max header size
    + server-side TCP receive window
    + server-side TCP send window

In a forward proxy, it's not difficult for the buffer space committed
for those four TCP windows to reach 256KB, and at that point the
choice of 4KB or 20KB for the header limit will have an impact less
than 10% on the total memory footprint.

With that said, however, I do think it might make life easier for
implementors if the number were slightly less than some multiple of
4KB, so that any necessary bookkeeping information for the buffer
(e.g., a length field, or a pointer to the memory slab out of which it
was allocated) could be stored in the same memory page as the buffer
on systems with 4KB pages.

-Brian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Jun 2011 09:03:43 +0200

> Standards should promote interoperability, not stupid behaviour.

Indeed. My observations in field is that clueless people justify their
stupid designs by "but look, it's permitted". Till now I've only been
able to show them they were doing stupid things by giving examples of
various implementations' limits, for instance by reminding them that
the ubiquitous Apache server had a 8kB limit per header and that that
should ring a bell in the guy's head.

Also Mark, I agree the Alteon would be faulty for 1.5kB right now, but
it was 10 years ago (WebOS 8). With WebOS 10 one year later, they
increased the limit to 4.5kB. But seeing that people were already able
to send about 2kB of cookies 10 years ago when DSL was still rare, we
surely can imagine what they'll do today if the standard suggests that
everything in the path should be able to support at least 20kB.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Jun 2011 19:24:33 +1000

> everything in the path should be able to support at least 20kB.

Understood. I'd also like to not have to revise HTTP again in another ten years :)

I think 20k made sense to me because of my experiences deploying proxies; however I agree we shouldn't be encouraging large headers. 

Anyone else with opinions?

---

From: Fred Bohle <[email-masked]>
Date: Wed, 22 Jun 2011 08:30:12 -0400

I couldn't let this go:  What recommendations DO you have for large people, and how they should make cookies?

:-)

Fred

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Jun 2011 14:43:22 +0200

> I couldn't let this go:  What recommendations DO you have for large people, and how they should make cookies?

As Mark explained it, we're not fixing a limit but indicating what a
minimal supported size should be. People using large values just have
to ensure that their large sizes is compatible with the involved
components. Suggesting that everyone is encouraged to support at least
4kB makes it easier to ensure that if you're below 4kB, it is very
unlikely that you'll encounter any issue.

BTW, RFC6265 suggests that agents are able to store cookies at least
4kB large, so all this is quite coherent. Basically for common usages,
you don't care. For specifically large usages, you'd better check.
Till now, you'd have to check whatever the size.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jun 2011 08:09:42 +1000

> I couldn't let this go:  What recommendations DO you have for large people, and how they should make cookies?

With choc chips?

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jun 2011 17:26:41 +1000

Haven't heard much. If we s/20k/4k/ in the header section, any other comments / suggestions / concerns?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 24 Jun 2011 07:34:17 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Haven't heard much. If we s/20k/4k/ in the header section, any other =
>comments / suggestions / concerns?

Not from here.

---

From: Brian Pane <[email-masked]>
Date: Fri, 24 Jun 2011 01:10:16 -0700

> Haven't heard much. If we s/20k/4k/ in the header section, any other comments / suggestions / concerns?

How about something like 4072 bytes instead of 4k?  That would give
the implementor some space for a length field and/or memory-management
bookkeeping inside the same page as the buffer, on systems with 4KB
pages.

-Brian

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Jun 2011 15:28:54 +0200

> >comments / suggestions / concerns?

Neither here :-)

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Jun 2011 15:33:00 +0200

> bookkeeping inside the same page as the buffer, on systems with 4KB

One specific value will never match all usages. For instance, I could
store those pages in trees which need more than 24 bytes on 64-bit
systems. The proposed value should be seen as a guideline to favor
interoperability and nothing more. If an implementation makes use of
4kB pages and need 64 bytes for page management, resulting in 4032
bytes, it will still be fine because the application which would
complain about the missing 64 bytes will once in a while be hit by
implementations respecting the 4096 bytes too.

So, while your point is completely valid as an optimisation principle,
we should not be that precise because it would become much more complex
to respect for many usages.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 24 Jun 2011 13:42:02 +0000

Queue has just published a great piece by Eric Allman which is
very relevant to think about in this context:

	http://queue.acm.org/detail.cfm?id=1999945

---

From: Brian Pane <[email-masked]>
Date: Fri, 24 Jun 2011 09:31:32 -0700

On Fri, Jun 24, 2011 at 6:33 AM, Willy Tarreau <[email-masked]> wrote:
> interoperability and nothing more.

I picked 24 bytes to allow for three pointers and/or counters on
64-bit systems, but I agree that a value larger than 24 would be a
good idea.  Given the prevalence of 64-byte cache lines, any number
between 1 byte and 63 bytes might as well be rounded up to 64 bytes.

> If an implementation makes use of

Generally speaking, I'm not worried about wasted space within a page.
In every nontrivial server and proxy implementation I've seen, buffers
for received messages are allocated in relatively large units -
multiples of 4KB or 8KB, for example.  A request that fits within,
say, 1KB will automatically lead to internal fragmentation.  And
that's fine; it's a totally valid design tradeoff.  The resource I'm
most interested in conserving isn't actually memory, it's TLB entries.

With that in mind, what do you think about 4000 bytes?  It's a nice
round number, but it gives the implementor more flexibility than 4096.

-Brian

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Jun 2011 20:02:27 +0200

> round number, but it gives the implementor more flexibility than 4096.

As I explained, we could use either of these because whoever
experiences an issue with one of these will certainly experience
issues with the other one too at some point.

Sure we can go with a round 4000, I'm fine with this too.

Regards,
Willy

---

From: David Morris <[email-masked]>
Date: Fri, 24 Jun 2011 11:05:18 -0700 (PDT)

Sounds like a good idea to me. I still professionally live in a dial-up
world so less is better.

Since I've not followed this topic from the beginning, I appologize if
the following is a repeat ... but it seems to me that the early/original
cookie specifcations allowed for a 4k cookie value? Folding multiple
values into a single header might be an issue. Might want to note that
if folding would cause the field length to be violated, then the
mulitple headers shouldn't be folded?

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Jun 2011 20:13:40 +0200

> mulitple headers shouldn't be folded?

Note that we're not speaking about a strict rule which could be violated,
just a hint about what size should have a high chance of passing without
complex verifications.

Many products will support more, but at least senders will know that if
they want to rely on more than 4kB they're among the rare people doing
so and that a validation of the whole chain would be a good idea before
thinking that everything will work out of the box. In short, this
recommendation should progressively motivate implementations to try to
send smaller headers, or at least not to waste too much space for no
reason.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 25 Jun 2011 12:38:20 +1000

Just to be clear -- we're talking about the total size of the *entire* header block here, not a single header limit.

Were the folks arguing for 4k assuming the former or the latter?

---

From: Brian Pane <[email-masked]>
Date: Fri, 24 Jun 2011 19:50:37 -0700

> Were the folks arguing for 4k assuming the former or the latter?

In my case, at least, the former: total size of the entire header block.

-Brian

---

From: Thomas Maslen <[email-masked]>
Date: Sat, 25 Jun 2011 04:41:51 +0000

> In my case, at least, the former: total size of the entire header block.

On the other end of the spectrum...

I work on server-side implementations (in various Java application servers) of HTTP Negotiate authentication (RFC 4559).

The "Authorization: Negotiate <Base64-blob>" headers that Windows clients send can be pretty big.  It is quite common for the HTTP header block to exceed 8 KB.  At one point I had convinced myself that 16 KB would always be comfortably large enough, but occasionally customers seem to run into trouble even then.

We are painfully aware of this because most of the HTTP implementations we deal with (various Java app servers, either with or without Apache HTTP Server front-ending them) default to an 8 KB limit on the size of the entire header block.  Thankfully, most of them provide a way to raise this limit, although a few do not (e.g. Jetty, IIRC).  Also, some of the connectors between Apache HTTP Server and Tomcat used to have a hard-coded protocol limit of 8 KB for the header block, although that has now been raised to 64 KB (16-bit length field in the protocol).

When an HTTP request hits the size limit, various servers respond in different ways, all of which lead to very puzzled customers.  Some servers send a 413 response (good).  Some just kill the connection and all you get to see is a TCP RST, which isn't very enlightening for debugging.  One app server did the nearest thing to a buffer overrun that you can do in Java.

Now, perhaps HTTP Negotiate authentication is not a compelling example because it is mostly used in enterprise intranets, not out on the public internet.

However, I believe that limited HTTP header sizes are also problematic for some protocols on the public internet.  In particular, it seems to me that the protocols federated single sign-on (Liberty, WS-Federation, SAML) from browsers ended up pretty contorted because they needed to send a largish authentication object (a SAML token) that they couldn't reliably send in HTTP headers, so the protocols had to resort to hackery such as using JavaScript to make the browser client automatically issue an HTTP POST with the authentication object in the message-body.  (Yes, I realize there were other issues than header-size limits, particularly the requirement to work in existing browsers with no code changes).

So:  colour me very much in favour of the s/4k/20k/g that Mark floated.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 25 Jun 2011 07:02:15 +0200

> In my case, at least, the former: total size of the entire header block.

Same here.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 25 Jun 2011 07:20:16 +0200

Hi Thomas,

> However, I believe that limited HTTP header sizes are also problematic for some protocols on the public internet.  In particular, it seems to me that the protocols federated single sign-on (Liberty…

You've described perfectly why recommending large values is the worst
thing to do : every time a large value is required, it is for a very
specific need, it causes a lot of trouble and in the end it can be
addressed correctly another way.

> So:  colour me very much in favour of the s/4k/20k/g that Mark floated.

That won't suddenly make the issues you encountered at 8k disappear. Quite
the opposite in fact, because instead of considering that anything above
4k requires double-checking, you'd blindly push your software everywhere
suggesting users that it will obviously cause no trouble since it's below
the 20k limit, but still their existing components will break as you
described above.

The recommended value is not a size limit. An application sending 100k can
be fine in some environments and still respect the rule. It's a bottom value
which any HTTP agent should always support, and that is safe to deal with.
As you showed it with your components, it's already not safe to bindly send
8k since it requires some specific configuration along the path.

Perhaps we could adapt the wording a bit (though I believe it was already
fine) to say something like :

   Various ad-hoc limitations on header length are found in practice. It is
   RECOMMENDED that all HTTP recipients support messages whose combined
   headers have 4,000 or more octets, so that it is always safe to send
   messages that large. Messages with larger headers might require specific
   configurations between the sender and the receiver and should not be
   considered as reliably deliverable without a preliminary check of the
   whole path.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 25 Jun 2011 06:58:07 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Just to be clear -- we're talking about the total size of the *entire* =
>header block here, not a single header limit.
>

I do not think we can set any numerical value for this property
which will satisfy everybody, but 4k is a sensible compromise between
seriously memory-starved gadgets (your future electricity meter)
and a reasonable level of cookie state, which surprisingly many of
these gadgets use.

Would this be too evil ?

	If the underlying transport protocol advertises or negotiates
	a receive buffer size, such as the TCP window, Clients
	SHOULD NOT send HTTP requests larger than this size.

This would allow really tiny implementations, such as Contiki, to
inform the world about their limits.

A server is still free to set a huge window to speed up POST, without
committing to accepting 2MB requests.

In most sensible socket implementations, socketoptions are inherited
from your accept socket to the accepted sockets, so a single setsockopt
can configure this on the server side.

I realize that not all socket implementations allow you to inspect
this number with getsockopt, but maybe this can inspire some kernel
network coders to provide that.

Also, I assume it is obvious to everybody, that the header size we
are talking about includes the two CRNL sequences at the end ?

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 25 Jun 2011 17:06:03 +1000

> and a reasonable level of cookie state, which surprisingly many of

Considering that there isn't any floor at the moment, I'm optimistic.

> inform the world about their limits.

That ignores proxies; the window size is effectively hop-by-hop (from an HTTP standpoint), and anyway this will cause people to complain about layer violations.

> are talking about includes the two CRNL sequences at the end ?

We'll need to go to that level of detail when we write the text, yes. It seems reasonable to include it.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 25 Jun 2011 07:10:32 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>That ignores proxies; the window size is effectively hop-by-hop (from an 
>HTTP standpoint), and anyway this will cause people to complain about 
>layer violations.

That is why it is only meant as a hint.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 25 Jun 2011 09:14:38 +0200

> That ignores proxies; the window size is effectively hop-by-hop (from an HTTP standpoint), and anyway this will cause people to complain about layer violations.

That's my fear too. Also it's more a matter of designing applications
to support a well-known value than to make UAs and servers agree on a
size : if your app requires large amounts of data to be sent, send them
as POST and not headers. Once the app is designed to work the wrong way,
whatever will be advertised by the other end will not change the issue,
if it can't work it's too late.

> We'll need to go to that level of detail when we write the text, yes. It seems reasonable to include it.

Indeed it was obvious to me too, as the request is only complete
once we get to that point.

Regards,
Willy

---

From: Karl Dubost <[email-masked]>
Date: Wed, 29 Jun 2011 15:30:50 -0400

> Haven't heard much. If we s/20k/4k/ in the header section, any other comments / suggestions / concerns?

What is the state of implementations right now?
What servers, proxies, libraries do?
Floor, ceiling, no limits, buffer overflows?

I was wondering if Steve Souders could get us stats.

    @souders any stats on the size distribution of 
    http headers see 
    http://www.w3.org/mid/[email-masked]
    — https://twitter.com/karlpro/status/86153476266147840

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Jun 2011 21:57:17 +0200

> Floor, ceiling, no limits, buffer overflows?

There are many different methods. Haproxy that I happen to know uses
a default limit of 7 or 8 kB (depening on build options) for the whole
headers, and is deployed that way at many places including some large
public sites. An older version used to default to 4kB for a long time,
but it was not as much deployed as today, so the lack of failure reports
would not count.

Apache 1.3, which I've worked a lot with used to support 8kB per line
and up to 101 lines (100 headers + request line) if my memory serves
me right. For others I don't remember.

The few times I got a report about haproxy blocking too large a message,
it was because of an application bug causing cookies to loop forever (eg:
server sends a set-cookie which appends the cookie value to all cookies
that were received).  

Of course we'll always find situations where default settings will have
to be changed whatever the component, but it seems like 4kB is a
reasonable value that many components will support without too much
efforts.

Concerning the behaviour upon errors, rejecting the request is the
most common one. Buffer overflow is not expected but used to happen
in tiny servers embedded in cheap WiFi routers or NAS servers. I'd
suspect that some servers are able to automatically reallocate more
space until they run out of memory. But quite frankly the goal is
much more to suggest something which should fit most uses and work
almost everywhere than to guess how a given agent or server handles
the failure.

> I was wondering if Steve Souders could get us stats.

It's not easy to guess, you never know what components are installed
between you and the site you're testing. You can just measure what
you observe at large sites and on large proxies. And even then, you
don't necessarily know if some broken communications automatically
fall back to more reasonable values.

For instance, I have a customer who recently got some reports about a
cookie number limit that was apparently reached for a few customers.
As a result, they'll probably remove a few cookies. So as you can see,
there's an automatic regulation when recommended limits are about to
be crossed.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 30 Jun 2011 07:35:15 +0000

>> Floor, ceiling, no limits, buffer overflows?

Varnish has three configurable limits:
	Number of lines.
	Total bytes
	Length of any one line.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Jun 2011 11:06:32 +0200

On 2011-06-22 02:58, Mark Nottingham wrote:
> ...

Looks good so far, with 20K replaced by 4000 octets, as discussed in 
this thread.

Question: I'm not sure servers actually send 413 when the *header 
fields* are too big -- does anybody know for sure? Otherwise we should 
test...

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 30 Jun 2011 11:13:21 +0200

> fields* are too big -- does anybody know for sure? Otherwise we should 

Haproxy currently sends 400 because I never understood that 413 was
made for this until this thread. I was planning on updating it to
emit 413 in newer versions.

Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Jun 2011 11:19:07 +0200

> emit 413 in newer versions.

I think I recall other servers doing that as well; will check with 
Tomcat and httpd later today.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 30 Jun 2011 09:20:52 +0000

>emit 413 in newer versions.

I also just changed Varnish to send 413 instead of 400.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 30 Jun 2011 22:44:11 +1200

> emit 413 in newer versions.

Ditto for squid. Was only waiting a consensus on this thread.

413 is currently only sent on too-big request body entities. I think due 
to interpretation of the old term/words "request entity".

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Jun 2011 13:29:07 +0200

> to interpretation of the old term/words "request entity".

Indeed. If we want to recommend 413 for this, we probably should tune 
that definition.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 30 Jun 2011 14:45:39 +0200

> Indeed. If we want to recommend 413 for this, we probably should tune 

Yes, RFC2616 used to introduce many terms which were not that common
and could be interpreted differently from what was expected. "Entity"
certainly was one of these.

Willy