Cool. The driver thread is technically a single threaded thing which shouldn't
block and the connection return functions are blocking but as the response is
small, it probably just works. Also, the connection code hasn't been verified
to run in the driver (filters, traces, etc.) but again it likely just works
unless there's a really goofy, blocking, involved filter lurking in some
installation.
A more involved, perhaps unnecessary solution would be to either move all the
response writing back to the driver in non-blocking I/O mode for all requests
and/or taking error condition connections and simply tightening them up and
sending them to a connection thread to generate the response safely. Hmm....
The later is probably safer/easier and more backward compatible but the former
concept always intrigued me.
Anyway, this patch sounds like a smart first step and can stop the bleeding on
the most common error response you'd want to know about, exceed content size.
-Jim
On Jun 24, 2011, at 1:00 AM, Gustaf Neumann wrote:
> Dear all,
>
> As a small contribution, i added a patch to sourceforge cvs. The patch
> returns the 413 error message via a new function
> Ns_ConnReturnEntityToLarge(), which is written in the same style as
> Ns_ConnReturnNotFound(). The patch is somewhat minimal and handles this issue
> entirely in the driver (also, forcing the log entry). I have paid no special
> attention to the custom response page.
>
> -gn
>
>
> On 23.06.11 19:14, Dossy Shiobara wrote:
>> That was what I was thinking -- driver marks the request as exceeding the
>> limit, and setting the response status code to 413. The benefits that I see
>> (if implemented the way I'm imagining) --
>>
>> 1) access logging of requests w/ 413 status code
>>
>> 2) custom response page via ns/server/${server}/redirects.
>>
>> If you and Brian could work up a patch, that'd be wonderful!
>>
>> Does anyone see any problems with this approach? Any reason not to do it?
>> I don't suppose it can possibly break any kind of backward compatibility, as
>> no code right now can even be written to handle such a scenario, anyway.
>>
>> Of course, once we decide on a behavior, and folks code against the
>> implementation ... changing/fixing it becomes more "expensive" for everyone,
>> so if there's any kind of worry about how this is going to work, lets iron
>> out the details now ;)
>>
>>
>> On 6/23/11 12:29 PM, Enrique Catalan wrote:
>>> IMHO, I agree with Dossy, to use the driver thread to check the hard
>>> limits and instead of dropping the connection, just mark the HTTP
>>> request and let the request handler to return the 413. I also think
>>> the template could be configured in the 'ns_section
>>> ns/server/${server}/redirects' , isn't it ?
>>>
>>> If you all agree with this, Brian and I can help to get a patch.
>>
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <lists...@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
> field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
