boa-devel Mailing List for Boa (Page 12)
Brought to you by:
jnelson
You can subscribe to this list here.
2000 |
Jan
(31) |
Feb
(42) |
Mar
(77) |
Apr
(8) |
May
(8) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
(20) |
Oct
(1) |
Nov
(11) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(9) |
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
|
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(7) |
Oct
(15) |
Nov
(6) |
Dec
(41) |
2003 |
Jan
(32) |
Feb
(20) |
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(12) |
2004 |
Jan
(2) |
Feb
(5) |
Mar
(5) |
Apr
(1) |
May
(10) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(8) |
2006 |
Jan
(10) |
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
(6) |
Jun
(13) |
Jul
(12) |
Aug
(13) |
Sep
(4) |
Oct
(23) |
Nov
(29) |
Dec
(26) |
2007 |
Jan
(15) |
Feb
(19) |
Mar
(29) |
Apr
(79) |
May
(74) |
Jun
(112) |
Jul
(44) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jon N. <jn...@ja...> - 2002-12-09 21:25:07
|
On 9 Dec 2002, Peter Korsgaard wrote: > Hi, > > As I was browsing through cgi.c trying to understand init_cgi I > noticed the following: > cgi.c:195 if (req->cgi_type == CGI || 1) { > > Any reason to keep this test? Not really. In (what will become) 0.94.14rc8 that test has already been changed. We violate the HTTP spec if we do, but I guess I don't care. nph- scripts are such a huge win processor-wise that it's a good idea. One thing about CGI that is not very easy to deal with (I think Apache does this wrong, too,) is killing runaway CGI processes, or CGI processes when Boa is shutdown. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Peter K. <ja...@su...> - 2002-12-09 21:05:16
|
Hi, As I was browsing through cgi.c trying to understand init_cgi I noticed the following: cgi.c:195 if (req->cgi_type == CGI || 1) { Any reason to keep this test? -- Bye, Peter Korsgaard |
From: Jon N. <jn...@ja...> - 2002-12-09 20:43:51
|
> Really minor, but I just noticed that the example boa.conf in > 0.94.14rc7 still claims that the config parser uses flex/bison, > instead of the current handcoded one. > > Furthermore the error message you get from an invalid directive is > imho a bit confusing - EG: > [09/Dec/2002:20:07:50 +0000] Line 195: Did not find keyword "Deny" > Invalid/unknown directive "Deny" is clearer to me. Both true, and both fixed. Thanks! -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Peter K. <ja...@su...> - 2002-12-09 20:41:48
|
>>>>> "Jon" == Jon Nelson <jn...@ja...> writes: Jon> Ideally, Boa should be able to call an external program to Jon> generate the indices, utilize an index.html (if it exists), call Jon> index.cgi (if it exists), *and* optionally cache the results, Jon> all in a logical, configurable fashion. Also, without incurring Jon> significant or unwarranted expenses of cycles or memory. I was looking at doing (a simplified) version of that last weekend for sunsite.dk, as Boa's CGI approach to directory indexing is quite CPU heavy on the big directories of our mirrors, and the builtin cacheable indexer is not that pretty ;) i didn't get around to finish it, but I'll have a look at it again later this week. Jon> That's a feature that's best left until the next release, I Jon> think, but code submissions are welcome. I'll see what comes out of this ;) -- Bye, Peter Korsgaard |
From: Peter K. <ja...@su...> - 2002-12-09 20:23:20
|
Hi, Really minor, but I just noticed that the example boa.conf in 0.94.14rc7 still claims that the config parser uses flex/bison, instead of the current handcoded one. Furthermore the error message you get from an invalid directive is imho a bit confusing - EG: [09/Dec/2002:20:07:50 +0000] Line 195: Did not find keyword "Deny" Invalid/unknown directive "Deny" is clearer to me. -- Bye, Peter Korsgaard |
From: Jon N. <jn...@ja...> - 2002-12-09 17:01:33
|
On 9 Dec 2002, Peter Korsgaard wrote: > Just a little notice that we have been running v0.94.14rc7 on > sunsite.dk for our mirrors for the last week without problems! Oooh, I just love to hear this. > The configure script failed to detect one of the system functions > (don't remember which on at the moment), I'll have a look at it and > create a patch if needed. I'd love to know which one failed. This is on Solaris, right? > I have updated the access control patch to 14rc7 at: > http://peter.korsgaard.com/software/boa.access-control.0.94.14rc7.patch > (remember to run autoconf after applying it, and configure with > --enable-access-control) Thanks! -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Jon N. <jn...@ja...> - 2002-12-09 14:26:42
|
On 8 Dec 2002, Elizabeth Barham wrote: > Dear All, > > It seems that this first patch to boa.c will correct the problem of > a root user running boa as root and the second patch is in regards to > the add_mime_type issue as the function is passed the data in the > opposite order as add_mime_types expects. That's so funny -- I had the exact same two patches in the source a day or so ago -- I just haven't made a new release candidate! -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Peter K. <ja...@su...> - 2002-12-09 06:44:32
|
Hi, Just a little notice that we have been running v0.94.14rc7 on sunsite.dk for our mirrors for the last week without problems! The configure script failed to detect one of the system functions (don't remember which on at the moment), I'll have a look at it and create a patch if needed. Furthermore I tried rc7 on Linux and Cygwin without problems. I have updated the access control patch to 14rc7 at: http://peter.korsgaard.com/software/boa.access-control.0.94.14rc7.patch (remember to run autoconf after applying it, and configure with --enable-access-control) -- Bye, Peter Korsgaard |
From: Elizabeth B. <li...@so...> - 2002-12-09 02:18:50
|
Dear All, It seems that this first patch to boa.c will correct the problem of a root user running boa as root and the second patch is in regards to the add_mime_type issue as the function is passed the data in the opposite order as add_mime_types expects. I am still pondering how to implement the CGI-DirectoryIndex thing. Elizabeth diff -ru3p boa-0.94.14rc7/src/boa.c boa-0.94.14rc7.modified/src/boa.c --- boa-0.94.14rc7/src/boa.c Mon Nov 11 20:50:50 2002 +++ boa-0.94.14rc7.modified/src/boa.c Sun Dec 8 19:43:01 2002 @@ -231,7 +231,7 @@ static void drop_privs(void) /* test for failed-but-return-was-successful setuid * http://www.securityportal.com/list-archive/bugtraq/2000/Jun/0101.html */ - if (setuid(0) != -1) { + if (server_uid != 0 && setuid(0) != -1) { DIE("icky Linux kernel bug!"); } } else { diff -ru3p boa-0.94.14rc7/src/config.c boa-0.94.14rc7.modified/src/config.c --- boa-0.94.14rc7/src/config.c Mon Nov 11 20:50:50 2002 +++ boa-0.94.14rc7.modified/src/config.c Sun Dec 8 20:00:59 2002 @@ -261,7 +261,7 @@ static void c_set_unity(char *v1, char * static void c_add_mime_type(char *v1, char *v2, void *t) { - add_mime_type(v1, v2); + add_mime_type(v2, v1); } void c_add_mime_types_file(char *v1, char *v2, void *t) |
From: Jon N. <jn...@ja...> - 2002-12-08 21:41:06
|
On 8 Dec 2002, Elizabeth Barham wrote: > la...@do... writes: > > > That is a useful option, especially when the machine > > sees only very light usage. It sucks for heavy load, > > where you need to create static index pages (maybe > > with automated, periodic update) instead. > > I looked at get.c and noticed that, as it currently is, having the > DirectoryIndex set to a CGI program does not work; the system tells the > client that the file is of type "application/x-httpd-cgi" (or > something similar) and delivers the contents of the file. > > A very simple work-around is to check the mimetype of the file that > is to be delivered in get_dir(). The only problem I forsee with this > approach is that get_mime_type will need be called twice (once in > get_dir() and the other in request.c, immediately prior to sending the > contents of the file). > > Another approach is to assign the file-to-be-delivered's mimetype > early on such as in the "struct request" similar to the filename > itself. That way, the hash lookup for the extension to mimetype > mapping will only need to be done once. > > Does this seem wise? Boa's automatic directory generation mechanisms have evolved over time but have not always been completely "clean". The current approach is to run an application (boa_indexer) with 2 arguments (the directory to index, and a title), which generates html as output. The program is run almost like it were a CGI, with a few minor differences. Boa also has the ability to build and cache directory indexes on-disk, using DirectoryCache directive (overridden by the DirectoryMaker directive). However, the indexes it builds are, uh, not very pretty. Ideally, Boa should be able to call an external program to generate the indices, utilize an index.html (if it exists), call index.cgi (if it exists), *and* optionally cache the results, all in a logical, configurable fashion. Also, without incurring significant or unwarranted expenses of cycles or memory. I suppose that it's probably *easiest* to extend the DirectoryIndex directive to accept more than one string, and to handle things from that perspective -- keep checking for index.html, index.htm, index.cgi until one of them is found (then performing the right thing, be it simply outputting a file or execing one, etc....) and fall back to the internal generator or the external one (or neither). That's a feature that's best left until the next release, I think, but code submissions are welcome. Oh, and to answer your other question, it's probably a good idea to store in the request struct the final mime-type, but I can't (without spending some time digging) immediately describe the best place to do that. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Jon N. <jn...@ja...> - 2002-12-08 21:33:18
|
On 7 Dec 2002, Elizabeth Barham wrote: > What are your opinions on DirectoryIndex being CGI application? I'll answer this in your follow-up question. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Jon N. <jn...@ja...> - 2002-12-08 21:32:05
|
On Sat, 7 Dec 2002, la...@do... wrote: > Elizabeth - > > > Is there any method to force Boa to not buffer cgi-bin output? > > This is what the "nph-" CGI is for. > It used to work, I hope it's not broken. > It does place additional burden on the program. > See examples/nph-test.cgi . It is not broken, but it has been disabled lately. I have re-enabled it and it works just fine. The code will appear in 0.94.14rc8 or 0.94.14 proper, whichever happens first. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Elizabeth B. <li...@so...> - 2002-12-08 06:28:21
|
la...@do... writes: > That is a useful option, especially when the machine > sees only very light usage. It sucks for heavy load, > where you need to create static index pages (maybe > with automated, periodic update) instead. I looked at get.c and noticed that, as it currently is, having the DirectoryIndex set to a CGI program does not work; the system tells the client that the file is of type "application/x-httpd-cgi" (or something similar) and delivers the contents of the file. A very simple work-around is to check the mimetype of the file that is to be delivered in get_dir(). The only problem I forsee with this approach is that get_mime_type will need be called twice (once in get_dir() and the other in request.c, immediately prior to sending the contents of the file). Another approach is to assign the file-to-be-delivered's mimetype early on such as in the "struct request" similar to the filename itself. That way, the hash lookup for the extension to mimetype mapping will only need to be done once. Does this seem wise? Thank you, Elizabeth |
From: Elizabeth B. <li...@so...> - 2002-12-07 21:24:50
|
la...@do... writes: > Elizabeth - > > > Is there any method to force Boa to not buffer cgi-bin output? > > This is what the "nph-" CGI is for. > It used to work, I hope it's not broken. > It does place additional burden on the program. > See examples/nph-test.cgi . Hi Larry, Okay. Thank you. What are your opinions on DirectoryIndex being CGI application? Elizabeth |
From: <la...@do...> - 2002-12-07 19:06:12
|
Elizabeth - > Is there any method to force Boa to not buffer cgi-bin output? This is what the "nph-" CGI is for. It used to work, I hope it's not broken. It does place additional burden on the program. See examples/nph-test.cgi . - Larry |
From: Elizabeth B. <li...@so...> - 2002-12-07 18:39:00
|
Jon Nelson <jn...@ja...> writes: > In the Boa code, it's a known that we're a bit overzealous in checking > for the bug -- it is true that sometimes it is appropriate to run as uid > 0. Before 0.94.14 is released, I would expect a simple fix in this > area. That would be awesome! Thank you! > What version of Boa are you using? 0.94.14rc7 writes data as soon > as it has been read -- prior versions did not do this. 0.94.13. I'll pull down the latest rc and work with it. Thanks a ton! Elizabeth |
From: Jon N. <jn...@ja...> - 2002-12-07 18:31:13
|
On 6 Dec 2002, Elizabeth Barham wrote: > Hi, > > First off, thank you very much for Boa. > > Just to let you all know, I had to modify boa.c: > > if (setuid(0) != -1) { > // Why is this a bug??? > // DIE("icky Linux kernel bug!"); > } There was an icky Linux kernel bug where apps could setuid themselves *back* to root after dropping root privs. In the Boa code, it's a known that we're a bit overzealous in checking for the bug -- it is true that sometimes it is appropriate to run as uid 0. Before 0.94.14 is released, I would expect a simple fix in this area. What version of Boa are you using? 0.94.14rc7 writes data as soon as it has been read -- prior versions did not do this. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: Elizabeth B. <li...@so...> - 2002-12-07 16:57:08
|
Elizabeth Barham writes: > Just to let you all know, I had to modify boa.c: > > if (setuid(0) != -1) { > // Why is this a bug??? > // DIE("icky Linux kernel bug!"); > } > > for Boa to run on a BusyBox boot-floppy system. I had best explain the situation: The system is attempting to run Boa *as root* *by root*. setuid(0) *should* work in this case. boa.conf contains: User root Group root From setuid(2): setuid sets the effective user ID of the current process. If the effective userid of the caller is root, the real and saved user ID's are also set. Under Linux, setuid is implemented like the POSIX version with the _POSIX_SAVED_IDS feature. This allows a setuid (other than root) program to drop all of its user privi leges, do some un-privileged work, and then re-engage the original effective user ID in a secure manner. If the user is root or the program is setuid root, special care must be taken. The setuid function checks the effec tive uid of the caller and if it is the superuser, all process related user ID's are set to uid. After this has occurred, it is impossible for the program to regain root privileges. (It's a root trying to setuid to root. -ed) Thus, a setuid-root program wishing to temporarily drop root privileges, assume the identity of a non-root user, and then regain root privileges afterwards cannot use setuid. You can accomplish this with the (non-POSIX, BSD) call seteuid. Elizabeth |
From: Elizabeth B. <li...@so...> - 2002-12-07 04:24:55
|
Hi, First off, thank you very much for Boa. Just to let you all know, I had to modify boa.c: if (setuid(0) != -1) { // Why is this a bug??? // DIE("icky Linux kernel bug!"); } for Boa to run on a BusyBox boot-floppy system. I am currently having some difficulty with the buffering of cgi-bin output. I wrote a little cgi-bin ash script [1] that does various networking things, one of these things is that it calls traceroute. As you probably know, traceroute flushes during the line and probably after the newline as well. But, however, when this script runs, the output does not come out as when run from the shell; rather, there is a period of inactivity followed by a burst of data, which happens again and again until all the output is done. I tested it originally with Apache and it did not have this problem. I have since tested it with Boa on the same box and the issue revealed itself again; the buffering issue can safely be localized to Boa. Is there any method to force Boa to not buffer cgi-bin output? Thank you, Elizabeth [1] <http://www.soggytrousers.net/repository/net-status> |
From: Jon N. <jn...@ja...> - 2002-12-05 18:36:24
|
On Thu, 5 Dec 2002, John P. Campbell wrote: > Thanks for the super fast response. I'm glad my mail prompted a bug > fix. However, the problem was something different. The error > message was a little misleading, as it has nothing to do with CGI > compliance. Running boa in gdb, I saw it wrote to the error log. > I should have looked there first. Sorry. > > from error_log... > > [05/Dec/2002:18:03:16 +0000] chdir: Permission denied > [05/Dec/2002:18:03:16 +0000] cgi_header: unable to find LFLF > > Mandrake created my home directory with 700 permissions. I wasn't > expecting that, so I never thought to look. To run a CGI, it tries > to chdir into that directory. Well, it couldn't. > > chmod +x /home/jpc fixed the whole thing. > > Maybe the error message should change if it can't chdir? I guess a > CGI in an unreadable location isn't compliant, though. :-) > > Anyway, thanks for a great product. Sure! I'll probably clean up that chdir message, too. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: John P. C. <jp...@xz...> - 2002-12-05 18:20:25
|
Thanks for the super fast response. I'm glad my mail prompted a bug fix. However, the problem was something different. The error message was a little misleading, as it has nothing to do with CGI compliance. Running boa in gdb, I saw it wrote to the error log. I should have looked there first. Sorry. from error_log... [05/Dec/2002:18:03:16 +0000] chdir: Permission denied [05/Dec/2002:18:03:16 +0000] cgi_header: unable to find LFLF Mandrake created my home directory with 700 permissions. I wasn't expecting that, so I never thought to look. To run a CGI, it tries to chdir into that directory. Well, it couldn't. chmod +x /home/jpc fixed the whole thing. Maybe the error message should change if it can't chdir? I guess a CGI in an unreadable location isn't compliant, though. :-) Anyway, thanks for a great product. jpc On Thu, Dec 05, 2002 at 10:17:51AM -0600, Jon Nelson wrote: > On Wed, 4 Dec 2002, John P. Campbell wrote: > Aha! You've found a bug in Boa! > I had the arguments to add_mime_type backwards in config.c: > > Index: config.c > =================================================================== > RCS file: /home/jnelson/cvs/boa/src/config.c,v > retrieving revision 1.31.2.13 > diff -u -r1.31.2.13 config.c > --- config.c 12 Nov 2002 02:50:50 -0000 1.31.2.13 > +++ config.c 5 Dec 2002 16:13:15 -0000 > @@ -261,7 +261,7 @@ > > static void c_add_mime_type(char *v1, char *v2, void *t) > { > - add_mime_type(v1, v2); > + add_mime_type(v2, v1); > } > > void c_add_mime_types_file(char *v1, char *v2, void *t) > > -- > Democracy is two wolves and a sheep voting on what to have for dinner. > Liberty is two wolves attempting to have a sheep for dinner and > finding a well-informed, well-armed sheep. > > Jon Nelson <jn...@ja...> > C and Python Code Gardener > > -- John P. Campbell Systems Developer xzuberant! Systems "There are 10 types of people in this world, those that understand binary and those that don't." |
From: Jon N. <jn...@ja...> - 2002-12-05 16:23:45
|
On Wed, 4 Dec 2002, John P. Campbell wrote: > This works from http://localhost/cgi-bin/test.cgi, but not from > http://localhost/~user/cgi-bin/test.cgi. Aha! You've found a bug in Boa! I had the arguments to add_mime_type backwards in config.c: Index: config.c =================================================================== RCS file: /home/jnelson/cvs/boa/src/config.c,v retrieving revision 1.31.2.13 diff -u -r1.31.2.13 config.c --- config.c 12 Nov 2002 02:50:50 -0000 1.31.2.13 +++ config.c 5 Dec 2002 16:13:15 -0000 @@ -261,7 +261,7 @@ static void c_add_mime_type(char *v1, char *v2, void *t) { - add_mime_type(v1, v2); + add_mime_type(v2, v1); } void c_add_mime_types_file(char *v1, char *v2, void *t) -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: John P. C. <jp...@xz...> - 2002-12-05 03:09:24
|
See bottom of post ... On Wed, Dec 04, 2002 at 08:47:52PM -0600, Jon Nelson wrote: > On Wed, 4 Dec 2002, John P. Campbell wrote: > > I am testing a simple cgi script. It's just a simple shell > > script to echo a string. > > > > ---cut--- > > #!/bin/sh > > > > echo Content-type: text/plain > > echo test script > > ---cut--- > > > > This works fine from if I use ScriptAlias to define the cgi-bin > > location. > > > > However, I'd like to make ~/public_html/cgi-bin a valid cgi directory > > as well to use for developers' sandboxes. > > > > Next I added: > > > > AddType application/x-httpd-cgi cgi > > > > and removed the ScriptAlias line. > > > > The script still works from the original cgi-bin dir (as expected). > > But the same script from ~/public_html/cgi-bin/ yields: > > > > 502 Bad Gateway > > The CGI was not CGI/1.1 compliant. > > I suspect they are not the same script. > The script as shown above should not work because it does not contain a > blank line between the headers and the content. Sorry, I accidentally deleted that echo line. The actual exact script is: -- cut -- #!/bin/sh -f echo Content-type: text/html echo echo test script -- cut -- This works from http://localhost/cgi-bin/test.cgi, but not from http://localhost/~user/cgi-bin/test.cgi. jpc |
From: Jon N. <jn...@ja...> - 2002-12-05 02:50:49
|
On Wed, 4 Dec 2002, John P. Campbell wrote: > I am testing a simple cgi script. It's just a simple shell > script to echo a string. > > ---cut--- > #!/bin/sh > > echo Content-type: text/plain > echo test script > ---cut--- > > This works fine from if I use ScriptAlias to define the cgi-bin > location. > > However, I'd like to make ~/public_html/cgi-bin a valid cgi directory > as well to use for developers' sandboxes. > > Next I added: > > AddType application/x-httpd-cgi cgi > > and removed the ScriptAlias line. > > The script still works from the original cgi-bin dir (as expected). > But the same script from ~/public_html/cgi-bin/ yields: > > 502 Bad Gateway > The CGI was not CGI/1.1 compliant. I suspect they are not the same script. The script as shown above should not work because it does not contain a blank line between the headers and the content. Adding an empty echo between the two above will correct this: ---- #! /bin/sh echo Content-type: text/plain echo echo test script ---- Give that a try and let us know what happens. If that doesn't work, we can dig a little deeper. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson <jn...@ja...> C and Python Code Gardener |
From: John P. C. <jp...@xz...> - 2002-12-04 22:59:44
|
I am testing a simple cgi script. It's just a simple shell script to echo a string. ---cut--- #!/bin/sh echo Content-type: text/plain echo test script ---cut--- This works fine from if I use ScriptAlias to define the cgi-bin location. However, I'd like to make ~/public_html/cgi-bin a valid cgi directory as well to use for developers' sandboxes. Next I added: AddType application/x-httpd-cgi cgi and removed the ScriptAlias line. The script still works from the original cgi-bin dir (as expected). But the same script from ~/public_html/cgi-bin/ yields: 502 Bad Gateway The CGI was not CGI/1.1 compliant. I've searched around but can't find much on this. Any suggestions? I'm running 0.94.13 release. Thanks, jpc -- John P. Campbell Systems Developer xzuberant! Systems "There are 10 types of people in this world, those that understand binary and those that don't." |