Hi,
[Sorry if this question was raised before, but I couldn't find anything related in the archives.]
How can I force a limit on the content size of the request body? Is there such a functionality built into hunchentoot? If not, is GET-POST-DATA the right place to introduce this feature?
Regards.
On Tue, Dec 30, 2008 at 14:58, Volkan YAZICI yazicivo@ttmail.com wrote:
How can I force a limit on the content size of the request body? Is there such a functionality built into hunchentoot? If not, is GET-POST-DATA the right place to introduce this feature?
I don't think that Hunchentoot can support a body size limitation in a meaningful way without major refactoring GET-POST-DATA. The WANT-STREAM argument to GET-POST-DATA, chunking and HTTP/0.9 support together make it impossible to enfore the limit in a fashion that would handle all use cases within the existing framework of the GET-POST-DATA function.
We are not quite happy with that situation, not only because there is no limit on the incoming request body, but also because of the RFC2388 parser that does not understand encodings. I am not sure whether we'll have the time to fix the problem ourselves soon, so if you can come up with a patch, we might be able to review and incorporate it into the upcoming release.
Please make sure that you read http://weitz.de/patches.html before you start. It might be good to discuss the implementation strategy here beforehand.
One approach would be to implement the limitation in a gray stream - That way, it may be possible to get away without changing the existing structure too much, but I have not investigated the possibility very deeply.
-Hans
On Tue, 30 Dec 2008, "Hans Huebner" hans.huebner@gmail.com writes:
I don't think that Hunchentoot can support a body size limitation in a meaningful way without major refactoring GET-POST-DATA. The WANT-STREAM argument to GET-POST-DATA, chunking and HTTP/0.9 support together make it impossible to enfore the limit in a fashion that would handle all use cases within the existing framework of the GET-POST-DATA function.
We are not quite happy with that situation, not only because there is no limit on the incoming request body, but also because of the RFC2388 parser that does not understand encodings. I am not sure whether we'll have the time to fix the problem ourselves soon, so if you can come up with a patch, we might be able to review and incorporate it into the upcoming release.
Please make sure that you read http://weitz.de/patches.html before you start. It might be good to discuss the implementation strategy here beforehand.
One approach would be to implement the limitation in a gray stream - That way, it may be possible to get away without changing the existing structure too much, but I have not investigated the possibility very deeply.
Considering your comparison, implementing the limitation in stream structures could be great. In case of a limitation failure, hunchentoot can signal a (restartable) condition. But I don't have an idea about how I could make flexi-streams to force such a limitation while reading streams. Would you mind giving some hints, reading pointers, etc. that I can further study?
Regards.
Happy New Year's, y'all!
On Wed, Dec 31, 2008 at 14:40, Volkan YAZICI yazicivo@ttmail.com wrote:
Considering your comparison, implementing the limitation in stream structures could be great. In case of a limitation failure, hunchentoot can signal a (restartable) condition. But I don't have an idea about how I could make flexi-streams to force such a limitation while reading streams. Would you mind giving some hints, reading pointers, etc. that I can further study?
I did not investigate this much, but here are two hints: The input stream that Hunchentoot gets from usocket is eventually wrapped in a flexi-stream. Before doing so, the stream could be wrapped in an instance of the length-limiting stream class that you have created. The SBCL manual has some helpful documentation and examples on gray streams, see (http://www.sbcl.org/manual/Gray-Streams.html).
Note that gray streams can be slow if you only supply methods for character wise reading. Things may still be fast enough, but you should keep an eye on performance.
Let us know if you need further pointers.
-Hans
-
Hans Huebner -
Volkan YAZICI