On Thu, Dec 12, 2013 at 3:54 PM, Kean Johnston <[email protected]>wrote:
> On 12/12/2013 10:11 PM, Jeff Trawick wrote: > >> There's nothing magic about it, and there is indeed the potential for a >> problem with the environment variable limitation. Generally I preferred >> to >> have a lower per-request memory use even if it takes another write to send >> all the envars to the application. >> > But if I am reading the code correctly, increasing that number wont > increase the per-request size at all, unless the environment is huge. If > the total environment only took say 2K, that's all that would be allocated. > All I can see from that limit I mentioned is limiting the size of 1 > individual environment entry. Admittedly not something you'd run into every > day but I can see no downside to making that be AP_FCGI_MAX_CONTENT_LEN. > Just my $0.02. I'm a complete Apache neophyte and you're a commiter so I > won't argue :) > Making it AP_FCGI_MAX_CONTENT_LEN (64K) is certainly not going to make any difference in most configurations, and in addition support the largest possible envvar... I'm sure I was coming at it from this angle: The original code wouldn't allow more than 64K *total* in envvar space; how could I allow a mostly arbitrary collection of envvars to be sent, though keeping small-ish I/O (as httpd does on the client side) buffers while sending large collections. One possibility was a more complex API for packing the buffers; another possibility was placing a limitation on the size that any particular envvar could take up. There's a happy medium -- generally using smaller buffers but making an exception for a huge envvar. The need for this would be triggered by the length calculation stopping before the end (like the warning message currently). Is this overkill? Probably so :) -- Born in Roswell... married an alien... http://emptyhammock.com/
