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

[sjamaan]

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!

[RvdH]

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.

[RvdH]

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

[sjamaan]

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.

[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.

[sjamaan]

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.

[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.

[sjamaan]

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.

[RvdH]

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.