Summary

Spiffy should signal request-header-fields-too-large upon (exn http line-limit-exceeded)

Metadata

Description

And see if there's also a matching error for (exn http header-limit-exceeded), while I'm at it.

But first see whether there will be no compatibility problems when doing this!

Changes and comments

[2013-11-22 15:10:04 UTC] sjamaan changed description

[2013-11-22 15:39:26 UTC] RvdH wrote:

RFC6585 (http://tools.ietf.org/html/rfc6585) says the following:

> It can be used both when the set of request header fields in total is too large, and when a single header field is at fault. In the latter case, the response representation SHOULD specify which header field was too large.

[2013-11-22 16:03:59 UTC] RvdH wrote:

Related: returning a 413 or 414 when the urlencoded-request-data-limit is exceeded.

[2013-11-24 13:07:08 UTC] sjamaan changed status from new to closed

[2013-11-24 13:07:08 UTC] sjamaan set resolution to wontfix

[2013-11-24 13:07:08 UTC] sjamaan wrote:

On second thought, let's not inform potential attackers any more than we have to. Just rudely disconnecting is the safest thing to do when someone is being rude in sending you bogus requests longer than you're willing to accept. It's a security setting after all!

It's unfortunate for the clients that accidentally cross the limit.

[2013-11-24 13:23:37 UTC] RvdH wrote:

Who said the requests were bogus? The HTTP specification does not specify a limit, so the client can't know what the limit is, unless the server sends a 431.

[2013-11-24 13:48:56 UTC] sjamaan wrote:

Replying to RvdH: > Who said the requests were bogus? The HTTP specification does not specify a limit, so the client can't know what the limit is, unless the server sends a 431.

What client is intelligent enough to fix the situation when it exceeds the length?

This information is only ever useful to developers, and they can either look in the logs or complain to the server's admin who can do the same.

[2013-11-24 16:18:18 UTC] RvdH wrote:

> What client is intelligent enough to fix the situation when it exceeds the length?

I know none. Yet RFC6585 (http://tools.ietf.org/html/rfc6585) was officially published in April 2012, so this is not very surprising.

[2013-11-24 16:26:50 UTC] sjamaan wrote:

Replying to RvdH: > > What client is intelligent enough to fix the situation when it exceeds the length? > > I know none. Yet RFC6585 (http://tools.ietf.org/html/rfc6585) was officially published in April 2012, so this is not very surprising.

But response codes 413 and 414 are much older (at their latest 1997) and I don't know any clients which are able to adjust their requests after receiving these, either.

[2013-11-24 16:51:53 UTC] RvdH wrote:

> But response codes 413 and 414 are much older (at their latest 1997) and I don't know any clients which are able to adjust their requests after receiving these, either.

I don't know any clients that adjust their requests on the fly, either. But what I do know is that if you're writing a client for a web service and you experience a 413 or 414, that you adjust your client's request, so that it won't error. In general you only have access to the server logs if you also wrote the server side, but that is rarely the case in my experience.

Actually, I believe a 413 is not so common. A 414 happens way more often, e.g. if you have to integrate with a service that returns search results based on various query parameters.