Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1073 closed defect (wontfix)

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

Reported by: sjamaan Owned by: sjamaan
Priority: major Milestone: someday
Component: extensions Version: 4.8.x
Keywords: spiffy error-handling Cc:
Estimated difficulty:

Description (last modified by 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!

Change History (9)

comment:1 Changed 8 years ago by sjamaan

Description: modified (diff)

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by RvdH

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

comment:4 Changed 8 years ago by sjamaan

Resolution: wontfix
Status: newclosed

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.

comment:5 Changed 8 years ago by 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.

comment:6 in reply to:  5 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by 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.

comment:8 in reply to:  7 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by 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.

Note: See TracTickets for help on using tickets.