I think this one case can be handled this way because you could truncate the
request (some content may have been read ahead) and then flag it for special
handling in the normal connection processing code/threads. The reason is the
server has a full request, you're just choosing to not read all the content, so
if you do a little touch up of the conn structure it can flow through the
connection threads without tripping up. I'm cautious here because I've spent a
lot of time in the past debugging half-baked conn problems. So, this patch
makes sense for the E_CRANGE error alone, the most annoying problem.
Later we could kick around the idea of getting the code in the driver to handle
much more detailed logging, dumping the access log module, etc.
-Jim
On Jun 23, 2011, at 11:14 AM, 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.
>
> --
> Dossy Shiobara | "He realized the fastest way to change
> do...@panoptic.com | is to laugh at your own folly -- then you
> http://panoptic.com/ | can let go and quickly move on." (p. 70)
> * WordPress * jQuery * MySQL * Security * Business Continuity *
>
>
> --
> 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.
