[PATCH] mod_fcgid: SEGV with empty output from fcgi process
Hello all, I found a problem that mod_fcgi makes segmentation fault when FastCGI process returns empty outout. It's caused with missing to check end of brigade when parsing CGI response header. I worte a patch to fix this, and attach on this mail. Please review. Regards, -- Tatsuki Sugiura mailto:s...@nemui.org mod_fcgi-fix-segv-with-empty-output.diff Description: Binary data
Re: mod_dav inconsistent behaviour for GET requests
Stefan Fritsch wrote: Hi, mod_dav doesn't handle GET requests in a consistent way: If a repos provider has handle_get == 1, mod_dav will handle GET requests by itself. This means no other handler will get a chance to interpret the file as script or SSI. On the other hand, if the repos provider has handle_get == 0, mod_dav will do nothing and another handler like mod_php or mod_include may handle scripts, causing the output of the script execution to be sent to the client instead of the script source. ... Lesson: don't serve the script's output and the script itself from the same URI. And if you really really have to, consider using the MS extension request header Translate. BR, Julian
RE: mod_dav inconsistent behaviour for GET requests
-Original Message- From: Stefan Fritsch Sent: Freitag, 29. Januar 2010 08:43 To: dev@httpd.apache.org Subject: mod_dav inconsistent behaviour for GET requests Hi, mod_dav doesn't handle GET requests in a consistent way: If a repos provider has handle_get == 1, mod_dav will handle GET requests by itself. This means no other handler will get a chance to interpret the file as script or SSI. On the other hand, if the repos provider has handle_get == 0, mod_dav will do nothing and another handler like mod_php or mod_include may handle scripts, causing the output of the script execution to be sent to the client instead of the script source. The documentation http://httpd.apache.org/docs/trunk/mod/mod_dav.html#complex suggests using ForceType 'text/plain' to circumvent this. Apart from the fact that this is not enough and one may need 'SetHandler none' as well, I think this is a kludge. mod_dav should make sure that the GET request is handled by the default handler by setting r-handler in its fixup hook. If nobody disagrees, I will change this in trunk. Please do not. Some mod_dav providers need to implement their own GET handler because the resource requested might not be a plain file (e.g. it is stored in the database). Apart from Julians comments, SSI is a filter and can be applied to these resources as well (no problem) and the same is true for PHP if mod_php is build as a filter. But usually: Use a different URL for WebDAV than for live access. Regards Rüdiger
Re: mod_dav inconsistent behaviour for GET requests
It seems my mail was not so clear. On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote: The documentation http://httpd.apache.org/docs/trunk/mod/mod_dav.html#complex suggests using ForceType 'text/plain' to circumvent this. Apart from the fact that this is not enough and one may need 'SetHandler none' as well, I think this is a kludge. mod_dav should make sure that the GET request is handled by the default handler by setting r-handler in its fixup hook. If nobody disagrees, I will change this in trunk. Please do not. Some mod_dav providers need to implement their own GET handler because the resource requested might not be a plain file (e.g. it is stored in the database). If this was not clear, I only want to change the behaviour for providers that do not implement their own GET handler, i.e. handle_get == 0. Apart from Julians comments, SSI is a filter and can be applied to these resources as well (no problem) and the same is true for PHP if mod_php is build as a filter. Ok, filters are a different problem, then. But my argument still stands for mod_php as handler. But usually: Use a different URL for WebDAV than for live access. That's what I want. But mod_dav makes it more difficult than necessary. Consider a configuration with mod_php like this: FilesMatch \.php$ SetHandler application/x-httpd-php /Files Location /dav Dav on /Location Then I want mod_dav to serve the script source for /dav/test.php but instead I will get the script output from mod_php. To get the script source, I currently need: Location /dav Dav on SetHandler none /Location In contrast, if I use a dav provider that handles GETs (like mod_dav_svn), I don't need the 'SetHandler none'. This is inconsistent. IMNSHO, if I set 'Dav on' for some Location, mod_dav has to ensure that it works, even for providers that don't handle GETs. Cheers, Stefan
Re: mod_dav inconsistent behaviour for GET requests
On Friday 29 January 2010, Julian Reschke wrote: And if you really really have to, consider using the MS extension request header Translate. Not all DAV clients send this header. Therefore it is not an option.
RE: mod_dav inconsistent behaviour for GET requests
-Original Message- From: Stefan Fritsch Sent: Freitag, 29. Januar 2010 11:26 To: dev@httpd.apache.org Subject: Re: mod_dav inconsistent behaviour for GET requests It seems my mail was not so clear. On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote: The documentation http://httpd.apache.org/docs/trunk/mod/mod_dav.html#complex suggests using ForceType 'text/plain' to circumvent this. Apart from the fact that this is not enough and one may need 'SetHandler none' as well, I think this is a kludge. mod_dav should make sure that the GET request is handled by the default handler by setting r-handler in its fixup hook. If nobody disagrees, I will change this in trunk. Please do not. Some mod_dav providers need to implement their own GET handler because the resource requested might not be a plain file (e.g. it is stored in the database). If this was not clear, I only want to change the behaviour for providers that do not implement their own GET handler, i.e. handle_get == 0. Apart from Julians comments, SSI is a filter and can be applied to these resources as well (no problem) and the same is true for PHP if mod_php is build as a filter. Ok, filters are a different problem, then. But my argument still stands for mod_php as handler. But usually: Use a different URL for WebDAV than for live access. That's what I want. But mod_dav makes it more difficult than necessary. Consider a configuration with mod_php like this: FilesMatch \.php$ SetHandler application/x-httpd-php /Files Location /dav Dav on /Location Then I want mod_dav to serve the script source for /dav/test.php but instead I will get the script output from mod_php. To get the script source, I currently need: Location /dav Dav on SetHandler none /Location In contrast, if I use a dav provider that handles GETs (like mod_dav_svn), I don't need the 'SetHandler none'. This is inconsistent. IMNSHO, if I set 'Dav on' for some Location, mod_dav has to ensure that it works, even for providers that don't handle GETs. Thanks for clarification. I guess I understand your intension better now. So basicly you want those providers that do not implement GET by themselves to enforce the usage of the default handler, correct? Mind to sent a patch to the list for better review? Regards Rüdiger
Re: mod_dav inconsistent behaviour for GET requests
On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote:
Thanks for clarification. I guess I understand your intension
better now. So basicly you want those providers that do not
implement GET by themselves to enforce the usage of the default
handler, correct?
Mind to sent a patch to the list for better review?
Exactly. The patch below works with 2.2 (haven't tested with trunk
due to lack of mod_php).
BTW, I found PR 13025, which seems to suggest that being able to mix
script execution and DAV on the same URL is a feature. I am still for
removing this 'feature' in trunk, though. But I would be against a
backport to 2.2.x.
--- a/modules/dav/main/mod_dav.c
+++ b/modules/dav/main/mod_dav.c
@@ -4803,12 +4803,13 @@ static int dav_fixups(request_rec *r)
/*
* If the repository hasn't indicated that it will handle the
- * GET method, then just punt.
- *
- * ### this isn't quite right... taking over the response can break
- * ### things like mod_negotiation. need to look into this some more.
+ * GET method, then we let the default handler do it. Set the handler
+ * explicitly to ensure that no other handler takes the request.
+ * We don't care about directories, though.
*/
if (!conf-provider-repos-handle_get) {
+if (r-finfo.filetype != APR_DIR)
+r-handler = none;
return DECLINED;
}
}
Re: mod_dav inconsistent behaviour for GET requests
On Jan 29, 2010, at 10:46 AM, Stefan Fritsch wrote:
On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote:
Thanks for clarification. I guess I understand your intension
better now. So basicly you want those providers that do not
implement GET by themselves to enforce the usage of the default
handler, correct?
Mind to sent a patch to the list for better review?
Exactly. The patch below works with 2.2 (haven't tested with trunk
due to lack of mod_php).
BTW, I found PR 13025, which seems to suggest that being able to mix
script execution and DAV on the same URL is a feature. I am still for
removing this 'feature' in trunk, though. But I would be against a
backport to 2.2.x.
--- a/modules/dav/main/mod_dav.c
+++ b/modules/dav/main/mod_dav.c
@@ -4803,12 +4803,13 @@ static int dav_fixups(request_rec *r)
/*
* If the repository hasn't indicated that it will handle the
- * GET method, then just punt.
- *
- * ### this isn't quite right... taking over the response can break
- * ### things like mod_negotiation. need to look into this some more.
+ * GET method, then we let the default handler do it. Set the handler
+ * explicitly to ensure that no other handler takes the request.
+ * We don't care about directories, though.
*/
if (!conf-provider-repos-handle_get) {
+if (r-finfo.filetype != APR_DIR)
+r-handler = none;
return DECLINED;
}
}
It looks to me like that would introduce a security hole for existing
configs that expect a handler to run on GET (PHP/CGI scripts that are
authorable via DAV). -1 if so.
Roy
