Re: Re: File upload problems still!
Sorry! I meant my population, as in the users of this program. This is only for members of a student group on campus. It will be open on the web, but anyone not in our member roster will be tossed out. My college career centers require word resumes for various resume book compilation, so everyone who needs to be on the CD has a word resume. I did not mean to imply that 100% of the world had their resumes in Word format! My mistake. :) Ryan - Original Message - From: Dennis Waller <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Roger C Haslock <[EMAIL PROTECTED]> Cc: Ryan Davis <[EMAIL PROTECTED]> Sent: Thursday, August 23, 2001 9:37 PM Subject: Re: Re: File upload problems still! > > > In the end, they are going to put on a resume CD, with a VB front end, > and Word > > is used to do keyword searches, and about 100% of the population involved > have > > their resumes in word anyway. > > --- > > > You are being pompous when you say that: No we don't . > > > > > > ___ > Send a cool gift with your E-Card > http://www.bluemountain.com/giftcenter/ > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sending @array as hidden variable
Hi Everybody,
I am trying to send an array as a hidden value in my script as follows:
@array = (eggs, ham, bread, pop);
foreach $food (@array){
print "";
}
My two questions are:
1. Is this the most efficient way of sending an array as a hidden value?
2. And if so, what is the corresponding $input{''} syntax?
Many thanks for your time, everybody!
=
#
Warmest Regards,
Simon K. Chan - [EMAIL PROTECTED]
"Great spirits have always encountered violent opposition from mediocre minds."
-Albert Einstein
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser Problem
Hello Curtis, It works!! Start Perl stuff... End Perl stuff... print< base-02.html Content container The:- print "Content-type: text/html\n\n"; produced a error in the browser for some reason. Many thanks for all your help. (I am not entirely certain of what is going on but it works!) Now I have to sort out the html/browser discrepancy problems. Opera and IE5.5 are pretty close but Netscape is doing strange things with my layout. Thanks again, Vance. --- --- Advance Design - Vance <[EMAIL PROTECTED]> wrote: > Hello Curtis, > > I am just returning a complete html document from the perl file ... Vance, It sounds like that could be the problem. Generally, when printing a Web page from a CGI script, you need to supply a content-type header to let the user agent (browser, in this case) know what type of content it's dealing with. If you're not doing that, your Web server might be doing that for you and sending a default of 'text/plain', or perhaps it's not sending it at all the the browsers are using defaults? Tough to say what's going on here. If you are not printing anything before the Web page, try printing the following: print "Content-type: text/html\n\n"; That will add the content-type header. Even better, try this (tougher to make a typo with this method): use CGI qw/:standard/; print header(); It sounds like you may be a little unsure as to what is meant by headers, so I'll try to explain, just in case. Your browser, when you request a resource from a Web server, will issue a request. There are many different request methods, but for CGI programmers, you will primarily be dealing with GET and POST requests. A typical request sent from your browser to the server may resemble the following: POST /cgi-bin/somescript.cgi HTTP/1.1 Accept */* Accept-Language: en-us Accept-encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) Host: www.someserver.com Connection: Keep-Alive color=red&name=Ovid Note that this request is split into two sections. The first section is comprised of the headers and the second section is the "entity body", or just "body". Since this is a POST request (see first line), "form" data is put in the entity body. If this were a GET request, there would be no body and the first line would be something like (note the query string moved from the body) GET /cgi-bin/somescript.cgi?color=red&name=Ovid HTTP/1.1 For a get request like the one above, you'll see something like the following in the address bar of your browser: http://www.someserver.com/cgi-bin/somescript.cgi?color=red&name=Ovid The Web server receives the request and passes your query information to the CGI script. When the CGI script responds, it is expected to send at least a Content-type header (unless your using non-parsed header scripts, which I won't go into now) or a status header (which I also won't go into now). Your Web server supplies the rest of the headers. Here's a typical response: a Web page sent by a script: HTTP/1.1 200 OK Date: Thu, 23 Sep 2001 06:23:19 GMT Server: Apache/1.3.6 (Unix) Last-Modified: Mon, 20 Sep 2001 08:19:56 GMT ETag: "2f5cd-9640381-e1bd6" Accept-Ranges: bytes Content-length: 4295 Connection: close Content-type: text/html base-02.html etc. Note that we again have headers and a body, just as an HTML document has a head and body, but we're talking apples and oranges here. Your script is expected to at least specify the content-type (note the last line of the headers) and the Web server usually provides the rest of the headers. The two newlines between the headers allows your browser to know where the headers stop and the entity-body begins. Typically, when you "view source" in a Web browser, you're seeing *only the entity-body* of the document that's been returned. Hope this clears up the confusion. For more information, you can read http://www.easystreet.com/~ovid/cgi_course/. Cheers, Curtis Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
RE: CGI::POST_MAX use and control
Justin, Whoops! Hadn't thought of that. Belt 'n suspenders is good. I'm sold. Besides, I'm am anthropomorphic enough to understand that my server has feelings, too. John-- [EMAIL PROTECTED] -Original Message- From: Justin Simoni [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 2:51 PM To: John Cc: Moon, John; Beginners-CGI Subject: Re: CGI::POST_MAX use and control > I'd thought of using JavaScript, but I'm sunk if the user has Jscript turned > off on their PC and I felt I wanted a little more surety on this being > checked. I am going to re-visit the idea, however.never hurts to do both, never hurts to do both, your server will thank you for the less POSTs you're giving it! justin. s k a z a t - http://skazat.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser Problem
--- Advance Design - Vance <[EMAIL PROTECTED]> wrote: > Hello Curtis, > > I am just returning a complete html document from the perl file ... Vance, It sounds like that could be the problem. Generally, when printing a Web page from a CGI script, you need to supply a content-type header to let the user agent (browser, in this case) know what type of content it's dealing with. If you're not doing that, your Web server might be doing that for you and sending a default of 'text/plain', or perhaps it's not sending it at all the the browsers are using defaults? Tough to say what's going on here. If you are not printing anything before the Web page, try printing the following: print "Content-type: text/html\n\n"; That will add the content-type header. Even better, try this (tougher to make a typo with this method): use CGI qw/:standard/; print header(); It sounds like you may be a little unsure as to what is meant by headers, so I'll try to explain, just in case. Your browser, when you request a resource from a Web server, will issue a request. There are many different request methods, but for CGI programmers, you will primarily be dealing with GET and POST requests. A typical request sent from your browser to the server may resemble the following: POST /cgi-bin/somescript.cgi HTTP/1.1 Accept */* Accept-Language: en-us Accept-encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) Host: www.someserver.com Connection: Keep-Alive color=red&name=Ovid Note that this request is split into two sections. The first section is comprised of the headers and the second section is the "entity body", or just "body". Since this is a POST request (see first line), "form" data is put in the entity body. If this were a GET request, there would be no body and the first line would be something like (note the query string moved from the body) GET /cgi-bin/somescript.cgi?color=red&name=Ovid HTTP/1.1 For a get request like the one above, you'll see something like the following in the address bar of your browser: http://www.someserver.com/cgi-bin/somescript.cgi?color=red&name=Ovid The Web server receives the request and passes your query information to the CGI script. When the CGI script responds, it is expected to send at least a Content-type header (unless your using non-parsed header scripts, which I won't go into now) or a status header (which I also won't go into now). Your Web server supplies the rest of the headers. Here's a typical response: a Web page sent by a script: HTTP/1.1 200 OK Date: Thu, 23 Sep 2001 06:23:19 GMT Server: Apache/1.3.6 (Unix) Last-Modified: Mon, 20 Sep 2001 08:19:56 GMT ETag: "2f5cd-9640381-e1bd6" Accept-Ranges: bytes Content-length: 4295 Connection: close Content-type: text/html base-02.html etc. Note that we again have headers and a body, just as an HTML document has a head and body, but we're talking apples and oranges here. Your script is expected to at least specify the content-type (note the last line of the headers) and the Web server usually provides the rest of the headers. The two newlines between the headers allows your browser to know where the headers stop and the entity-body begins. Typically, when you "view source" in a Web browser, you're seeing *only the entity-body* of the document that's been returned. Hope this clears up the confusion. For more information, you can read http://www.easystreet.com/~ovid/cgi_course/. Cheers, Curtis Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser Problem
Hello Curtis, I am just returning a complete html document from the perl file using the following: (perl in blue, html in red) Start Perl stuff... End Perl stuff... print< base-02.html Content container Your email suggests I should have a content-type header included in here somewhere... ? Thanks for your help. Vance [EMAIL PROTECTED] www.advance-design.co.uk --- Advance Design - Vance <[EMAIL PROTECTED]> wrote: > Hello > I have written some web pages incorporating Forms and Perl processing on the server. >Everything > works fine on my IE 5.5 Browser but when I use the Netscape 4.7 and Opera 5.12 >browsers, the > HTML sent back from the Perl programme appears as (source) text. > Do you have any ideas why. > > Thanks > Newer versions of Internet Explorer have a "feature" that examines that beginning of >the data that > it receives and attempts to render the data accordingly. It completely violates W3C >standards by > ignoring the content-type header. Many, many developers have been bitten by this >bug. I've > accidently sent GIFs with a content type of image/pjpeg and IE still rendered it >correctly but > Netscape didn't. That was less than fun to debug. > In your script, find out what is responsible for printing the content-type header >and post that > code snippet here. It will be something like the following: > # If you're doing it by hand, it will resemble this: > print "Content-type: text/html\n\n"; > # If you're using CGI.pm, it will resemble on of the two following lines: > print header(); > # or (varies depending on the name of the CGI object) > print $query->header; > There are many different ways of printing the content-type header, but they will >likely resemble > the snippets above. Send that and we may have an answer for you. > Of course, you can also telnet to port 80 (assuming that's the telnet port) and view >the headers > that way). Most likely, you're sending a content type of 'text/plain'. Here's what >you'd enter > in telnet: > GET /cgi-bin/somescript.cgi?foo=bar HTTP/1.1 > Host: www.somehost.com > Substitute your own host and path and make sure you have two newlines after the host >header. > Cheers, > Curtis Poe > = > Senior Programmer > Onsite! Technology (http://www.onsitetech.com/) > "Ovid" on http://www.perlmonks.org/ > __ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/
Re: Fw: Browser Problem
--- Advance Design - Vance <[EMAIL PROTECTED]> wrote: > Hi Joel, > Thanks for the fast reply. > This is the html document heads. > > I have tried "messing" about with these, but with > no change in result. > > Transitional//EN"> > > > base-02.html > > > > content="keyword,keyword"> > Actually, that's the head of the HTML document. What's needed are the headers that are sent *prior* to that. Those headers tell the user agent (the browser, in this case) what to do with the document. Cheers, Curtis Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sendmail and newlines
Situation: My perl script (see Code: below) is being
handed a flatfile (see File: below) generated from a
database to do a mass mailing that will send a message
generic to the flatfile but with each recepient
receiving a unique username and password.
The message part of the file is being input by a list
administrator through an oracle tool (I think, I
didn't develop that in anyway) and the ability to have
newlines is necessary for formatting. The problem is
when this message is dumped into the flatfile, the
newlines are still in it and cause the script to go
nuts.
My idea was to have the newlines in the message
replaced with \\n before being put into the flatfile
(which is what I have done in my test file). I then
attempt to replace the \\n with \n in the $message
field for sending.
It kind of works. (see Output: below) I get the
newlines now, but i also get one \ just out there. I
have tried many variations, but having \\n and
replacing with \n seems to be the only way to get a
newline to work, but how to get rid of the extra \?
Any suggestions would be very very appreciated.
TIA
Code:
#!/usr/bin/perl
$mailprog = '/usr/sbin/sendmail -t';
$admin_email="decoraw\@act.org";
$subject="Testing the new mass mailer";
$file =
"/actapps/suitespot/cgi-bin/sender/returntest3.txt";
$number_sent = 0;
open(DATA, "$file") || die "Can't open $file"; # open
the file for reading
while($line = )
{
chomp $line;
($junk,$email,$message,$survey_url,$login,$password)
= split(/\|/,$line);
$message =~ s|\\n|\n|g; #replace the escaped
newlines with newlines for formatting
open (MAIL, "|$mailprog -t") || die "Can't open
$mailprog! \n";
print MAIL "Content-type:text/plain\n";
print MAIL "From: $admin_email\n";
print MAIL "To: $email\n";
print MAIL "Subject: $subject\n";
print MAIL "$message\n\n";
print MAIL "URL: $survey_url\n";
print MAIL "Login: $login\n";
print MAIL "Password: $password\n";
close(MAIL);
$number_sent++;
}
File:
|[EMAIL PROTECTED]|This is my message.\\nI hope
these returns will work this
time.\\nWendy|http://www.mysite.com/index.html|3|3|
Output:
This is my message.\
I hope these returns will work this time.\
Wendy
URL: http://www.mysite.com/index.html Login: 3
Password: 3
=
Wendy
Webmistress
My computer has an Emmy, how 'bout yours?
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration Files
Darren, try App::Config Jeffl On 2001.08.23 15:27 darren chamberlain wrote: > James Kelty <[EMAIL PROTECTED]> said something to this effect on > 08/23/2001: > > I would like to set up a configuration file for a CGI that I am writing > > so that it will be portable without > > editing the actual cgi. Stuff like administator email's, network > > segments, and the like. > > > > Is there a way to source the file for the cgi to read, or do I have to > > add a require statment and make the file a user routine? > > There are a few ways to do it. > > Easiest is to have the config file be valid perl, and call it > like: > > require "/path/to/config.pl"; > > There are plenty of modules on CPAN to read config files; my > favorite is Config::General, which allows for (among other > things) Apache-style config files. Config::Ini is also supposed > to be good, and there is also the AppConfig package. > > (darren) > > -- > Students achieving Oneness will move on to Twoness. > -- Woody Allen > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration Files
James Kelty <[EMAIL PROTECTED]> said something to this effect on 08/23/2001: > I would like to set up a configuration file for a CGI that I am writing > so that it will be portable without > editing the actual cgi. Stuff like administator email's, network > segments, and the like. > > Is there a way to source the file for the cgi to read, or do I have to > add a require statment and make the file a user routine? There are a few ways to do it. Easiest is to have the config file be valid perl, and call it like: require "/path/to/config.pl"; There are plenty of modules on CPAN to read config files; my favorite is Config::General, which allows for (among other things) Apache-style config files. Config::Ini is also supposed to be good, and there is also the AppConfig package. (darren) -- Students achieving Oneness will move on to Twoness. -- Woody Allen -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Browser Problem
Check any 'Content-type' header that you send. The header should be 'Content-type: text/html'. If you are not sending a 'Content-type' header, then you should be. To do this simply put one of the following statements in your code: # if you are using Lincoln Stein's CGI.pm module. print CGI->header(); or # if you are NOT using Lincoln Stein's CGI.pm module. print "Content-type: text/html\n\n"; The reason the HTML is being read as plain text, is due to the fact Netscape and Opera are being the content is 'Content-type: text/plain'. Bradley M. Handy Senior Programmer/Owner Jack-of-all-trades Programming Services --www.jack-of-all-trades.net --mailto:[EMAIL PROTECTED] > -Original Message- > From: Advance Design - Vance [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 23, 2001 2:18 PM > To: [EMAIL PROTECTED] > Subject: Browser Problem > > > Hello > I have written some web pages incorporating Forms and Perl > processing on the server. Everything works fine on my IE 5.5 > Browser but when I use the Netscape 4.7 and Opera 5.12 browsers, > the HTML sent back from the Perl programme appears as (source) text. > Do you have any ideas why. > > Thanks > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuration Files
Hello. I would like to set up a configuration file for a CGI that I am writing so that it will be portable without editing the actual cgi. Stuff like administator email's, network segments, and the like. Is there a way to source the file for the cgi to read, or do I have to add a require statment and make the file a user routine? -James -- James Kelty Sr. Unix Systems Administrator The Ashland Agency [EMAIL PROTECTED] 541.488.0801 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI::POST_MAX use and control
> I'd thought of using JavaScript, but I'm sunk if the user has Jscript turned > off on their PC and I felt I wanted a little more surety on this being > checked. I am going to re-visit the idea, however.never hurts to do both, never hurts to do both, your server will thank you for the less POSTs you're giving it! justin. s k a z a t - http://skazat.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: Browser Problem
Hi Joel, Thanks for the fast reply. This is the html document heads. I have tried "messing" about with these, but with no change in result. base-02.html Thanks, Vance. [EMAIL PROTECTED] - Original Message - From: "Joel Hughes" <[EMAIL PROTECTED]> To: "Advance Design - Vance" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, August 23, 2001 7:29 PM Subject: RE: Browser Problem > maybe you've made a mistake with your HTTP headers which IE5.5 is being > forgiving about but Opera and Netscape are complaining about (Opera is quite > strict - which is good of course!). > > Can you check the headers that you are producing and post them to the group? > > regards > > Joel > > -Original Message- > From: Advance Design - Vance [mailto:[EMAIL PROTECTED]] > Sent: 23 August 2001 19:18 > To: [EMAIL PROTECTED] > Subject: Browser Problem > > > Hello > I have written some web pages incorporating Forms and Perl processing on the > server. Everything works fine on my IE 5.5 Browser but when I use the > Netscape 4.7 and Opera 5.12 browsers, the HTML sent back from the Perl > programme appears as (source) text. > Do you have any ideas why. > > Thanks > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser Problem
--- Advance Design - Vance <[EMAIL PROTECTED]> wrote: > Hello > I have written some web pages incorporating Forms and Perl processing on the server. >Everything > works fine on my IE 5.5 Browser but when I use the Netscape 4.7 and Opera 5.12 >browsers, the > HTML sent back from the Perl programme appears as (source) text. > Do you have any ideas why. > > Thanks Newer versions of Internet Explorer have a "feature" that examines that beginning of the data that it receives and attempts to render the data accordingly. It completely violates W3C standards by ignoring the content-type header. Many, many developers have been bitten by this bug. I've accidently sent GIFs with a content type of image/pjpeg and IE still rendered it correctly but Netscape didn't. That was less than fun to debug. In your script, find out what is responsible for printing the content-type header and post that code snippet here. It will be something like the following: # If you're doing it by hand, it will resemble this: print "Content-type: text/html\n\n"; # If you're using CGI.pm, it will resemble on of the two following lines: print header(); # or (varies depending on the name of the CGI object) print $query->header; There are many different ways of printing the content-type header, but they will likely resemble the snippets above. Send that and we may have an answer for you. Of course, you can also telnet to port 80 (assuming that's the telnet port) and view the headers that way). Most likely, you're sending a content type of 'text/plain'. Here's what you'd enter in telnet: GET /cgi-bin/somescript.cgi?foo=bar HTTP/1.1 Host: www.somehost.com Substitute your own host and path and make sure you have two newlines after the host header. Cheers, Curtis Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
John,
Thanks for the idea.
I'd thought of using JavaScript, but I'm sunk if the user has Jscript turned
off on their PC and I felt I wanted a little more surety on this being
checked. I am going to re-visit the idea, however.
My current Perl code does catch the error and return a form to the user so
that they can reflect on their evil ways and correct their misdeeds. The
script won't abort on 'em. (I'm considering a file-based counter, so that
maybe the third time the same user flubs up I can really slap their paw,
however; but that's an "enhancement" )
Thanks.
John--
[EMAIL PROTECTED]
-Original Message-
From: Moon, John [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 2:22 PM
To: John
Cc: Beginners-CGI
Subject: RE: CGI::POST_MAX use and control
For myself I would prefer not to "abort" a script on this type of error...
A simple JavaScript to check for the max size of a textarea and an "alert"
is a much better way to handle this type of error, in my option... see
"OnSubmit" in some JavaScript reference and you should be able to find an
example like ..
O'Reilly's "JavaScript The Definitive Guide", Chapter 16: Forms and Form
Elements, 16.5 Form Verification Example
Hope this give you some ideas...
jwm
-Original Message-
From: Lisa Nyman [mailto:[EMAIL PROTECTED]]
Sent: August 23, 2001 13:20
To: John
Cc: Beginners-CGI
Subject: Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
> The current incarnation of my script blows itself out of the water if the
> $user_body variable (the TEXTAREA source) is greater than 4K, for example.
> This is good.
>
> I would like to be able to capture and control the process so that I don't
> get rudely blown out of the water with a crude 500 Server message (this
> would be gooder! ). I would like to: a)generate a useful message and,
b)
> set some flags, do some more processing, and send a message back to the
user
> to give them an opportunity to correct their input and atone for their
sins.
> (This would be more gooder! )
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page->header;
$run = $page->param('RUN');
if (!$run && cgi_error()) {
# do whatever you do for an error
&dieWell ("413: Max Posting surpassed.");
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print "$thanks_for_playing_message\n";
# do logging of $message if you want, send yourself email, whatever
&footer; # end my html -
exit;
}
Lisa Wolfisch Nyman <[EMAIL PROTECTED]> IT Warrior Princess
"Life is too short to wear ugly underwear."
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
For myself I would prefer not to "abort" a script on this type of error...
A simple JavaScript to check for the max size of a textarea and an "alert"
is a much better way to handle this type of error, in my option... see
"OnSubmit" in some JavaScript reference and you should be able to find an
example like ..
O'Reilly's "JavaScript The Definitive Guide", Chapter 16: Forms and Form
Elements, 16.5 Form Verification Example
Hope this give you some ideas...
jwm
-Original Message-
From: Lisa Nyman [mailto:[EMAIL PROTECTED]]
Sent: August 23, 2001 13:20
To: John
Cc: Beginners-CGI
Subject: Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
> The current incarnation of my script blows itself out of the water if the
> $user_body variable (the TEXTAREA source) is greater than 4K, for example.
> This is good.
>
> I would like to be able to capture and control the process so that I don't
> get rudely blown out of the water with a crude 500 Server message (this
> would be gooder! ). I would like to: a)generate a useful message and,
b)
> set some flags, do some more processing, and send a message back to the
user
> to give them an opportunity to correct their input and atone for their
sins.
> (This would be more gooder! )
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page->header;
$run = $page->param('RUN');
if (!$run && cgi_error()) {
# do whatever you do for an error
&dieWell ("413: Max Posting surpassed.");
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print "$thanks_for_playing_message\n";
# do logging of $message if you want, send yourself email, whatever
&footer; # end my html -
exit;
}
Lisa Wolfisch Nyman <[EMAIL PROTECTED]> IT Warrior Princess
"Life is too short to wear ugly underwear."
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Browser Problem
maybe you've made a mistake with your HTTP headers which IE5.5 is being forgiving about but Opera and Netscape are complaining about (Opera is quite strict - which is good of course!). Can you check the headers that you are producing and post them to the group? regards Joel -Original Message- From: Advance Design - Vance [mailto:[EMAIL PROTECTED]] Sent: 23 August 2001 19:18 To: [EMAIL PROTECTED] Subject: Browser Problem Hello I have written some web pages incorporating Forms and Perl processing on the server. Everything works fine on my IE 5.5 Browser but when I use the Netscape 4.7 and Opera 5.12 browsers, the HTML sent back from the Perl programme appears as (source) text. Do you have any ideas why. Thanks -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
Lisa,
Thanks!
I synthesized from your answer and realized that my use of 'use CGI::Carp
qw/fatalsToBrowser/;' was having me die long before I could have the code
handle the problem. I commented out the '...Carp...' block and, indeed, my
builtin code handled the error the way I'd intended.
I was even able to see my 'friendly' ;-) user's error message: "Because your
message was too long, we ran out of electrons. Please shorten your e-mail
message.". When I shortened the message to less than the 4K I spec'd, the
form and code did the right thing and produced the intended e-mail.
Follow-up question: Does POST_MAX measure the length of the incoming stream
as the code asks for it -- $recd_data = $form->param('sent_data'); -- and
then pulls the plug if 'sent_data' goes outside the bounds of acceptable
social behavior?
I ask because, while this change worked in my current program, I want to
more fully understand the working principles for my next system.
Thanks.
John--
[EMAIL PROTECTED]
-Original Message-
From: Lisa Nyman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 1:20 PM
To: John
Cc: Beginners-CGI
Subject: Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
> The current incarnation of my script blows itself out of the water if the
> $user_body variable (the TEXTAREA source) is greater than 4K, for example.
> This is good.
>
> I would like to be able to capture and control the process so that I don't
> get rudely blown out of the water with a crude 500 Server message (this
> would be gooder! ). I would like to: a)generate a useful message and,
b)
> set some flags, do some more processing, and send a message back to the
user
> to give them an opportunity to correct their input and atone for their
sins.
> (This would be more gooder! )
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page->header;
$run = $page->param('RUN');
if (!$run && cgi_error()) {
# do whatever you do for an error
&dieWell ("413: Max Posting surpassed.");
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print "$thanks_for_playing_message\n";
# do logging of $message if you want, send yourself email, whatever
&footer; # end my html -
exit;
}
Lisa Wolfisch Nyman <[EMAIL PROTECTED]> IT Warrior Princess
"Life is too short to wear ugly underwear."
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does Apache invoke Perl interpreter
On Thu, 23 Aug 2001, Qichao Dong (Leon) wrote: > I want to do some research on Perl's transplantability, so I would like to > know how an Apache server invokes Perl interpreter - in the case of > mod_cgi instead of mod_perl. Have you tried http://perl.apache.org? -- Brett http://www.chapelperilous.net/ In every non-trivial program there is at least one bug. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Browser Problem
Hello I have written some web pages incorporating Forms and Perl processing on the server. Everything works fine on my IE 5.5 Browser but when I use the Netscape 4.7 and Opera 5.12 browsers, the HTML sent back from the Perl programme appears as (source) text. Do you have any ideas why. Thanks
RE: How does Apache invoke Perl interpreter: OT please don't reply
test -Original Message- From: Qichao Dong (Leon) [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 2:21 PM To: [EMAIL PROTECTED] Subject: How does Apache invoke Perl interpreter Hi, I want to do some research on Perl's transplantability, so I would like to know how an Apache server invokes Perl interpreter - in the case of mod_cgi instead of mod_perl. If anyone knows, or can redirect me to some documentation on the mechanism of Apache, please give me a hint. Thank you. Leon Qichao Dong(Leon) Graduate Research Assistant Innovative Computing Lab Computer Science Dept.University of Tennessee, Knoxville (865)974-9985 [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How does Apache invoke Perl interpreter
Hi, I want to do some research on Perl's transplantability, so I would like to know how an Apache server invokes Perl interpreter - in the case of mod_cgi instead of mod_perl. If anyone knows, or can redirect me to some documentation on the mechanism of Apache, please give me a hint. Thank you. Leon Qichao Dong(Leon) Graduate Research Assistant Innovative Computing Lab Computer Science Dept.University of Tennessee, Knoxville (865)974-9985 [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weekly list FAQ posting
NAME beginners-faq - FAQ for the beginners-cgi mailing list 1 - Administriva 1.1 - I'm not subscribed - how do I subscribe? Send mail to <[EMAIL PROTECTED]> You can also specify your subscription email address by sending email to (assuming [EMAIL PROTECTED] is your email address): <[EMAIL PROTECTED]>. 1.2 - How do I unsubscribe? Now, why would you want to do that? Send mail to <[EMAIL PROTECTED]>, and wait for a response. Once you reply to the response, you'll be unsubscribed. If that doesn't work, find the email address which you are subscribed from and send an email like the following (let's assume your email is [EMAIL PROTECTED]): <[EMAIL PROTECTED]> 1.3 - There is too much traffic on this list. Is there a digest? Yes. To subscribe to the digest version of this list send an email to: <[EMAIL PROTECTED]> To unsubscribe from the digest, send an email to: <[EMAIL PROTECTED]> 1.4 - Is there an archive on the web? Yes, there is. It is located at: http://archive.develooper.com/beginners-cgi%40perl.org/ 1.5 - How can I get this FAQ? This document will be emailed to the list once a month, and will be available online in the archives, and at http://beginners.perl.org/ 1.6 - I don't see something in the FAQ, how can I make a suggestion? Send an email to <[EMAIL PROTECTED]> with your suggestion. 1.7 - Is there a supporting website for this list? Yes, there is. It is located at: http://beginners.perl.org/ 1.8 - Who owns this list? Who do I complain to? Casey West owns the beginners-cgi list. You can contact him at [EMAIL PROTECTED] 1.9 - Who currently maintains the FAQ? Kevin Meltzer, who can be reached at the email address (for FAQ suggestions only) in question 1.6 1.10 - Who will maintain peace and flow on the list? Casey West, Kevin Meltzer and Ask Bjoern Hansen currently carry large, yet padded, clue-sticks to maintain peace and order on the list. If you are privately emailed by one of these folks for flaming, being off-topic, etc... please listen to what they say. If you see a message sent to the list by one of these people saying that a thread is closed, do not continue to post to the list on that thread! If you do, you will not only meet face to face with a XQJ-37 nuclear powered pansexual roto-plooker, but you may also be taken off of the list. These people simply want to make sure the list stays topical, and above-all, useful to Perl/CGI beginners. 1.11 - When was this FAQ last updated? May 31, 2001 2 - Questions about the 'beginners-cgi' list. 2.1 - What is the list for? A list for beginning Perl programmers to ask questions in a friendly atmosphere. The topic of the list is, of course, CGI with Perl. 2.2 - What is this list _not_ for? * SPAM * Homework * Solicitation * Things that aren't Perl related * Non Perl/CGI questions or issues * Lemurs 2.3 - Are there any rules? Yes. As with most communities, there are rules. Not many, and ones that shouldn't need to be mentioned, but they are. * Be nice * No flaming * Have fun 2.4 - What topics are allowed on this list? Basically, if it has to do with Perl/CGI , then it is allowed. If your question has nothing at all to do with Perl/CGI, it will likely be ignored. 2.5 - I want to help, what should I do? Subscribe to the list! If you see a question which you can give an idiomatic and Good answer to, answer away! If you do not know the answer, wait for someone to answer, and learn a little. 2.6 - Is there anything I should keep in mind while answering? We don't want to see 'RTFM'. That isn't very helpful. Instead, guide the beginner to the place in the FM they should R :) 2.7 - I don't want to post a question if it is in an FAQ. Where should I look first? Look in the FAQ! Get acquainted with the 'perldoc' utility, and use it. It can save everyone time if you look in the Perl FAQs first, instead of having a list of people refer you to the Perl FAQs :) You can learn about 'perldoc' by typing: `perldoc perldoc' At your command prompt. You can also view documentation online at: http://www.perldoc.com and http://www.perl.com 3 - Other Resources 3.1 - What other websites may be useful to a beginner ? * Perl Home Page - http://www.perl.com * PerlMonks - http://www.perlmonks.org * Perldoc - http://www.perldoc.com * Perl Archives - http://www.perlarchives.com 3.2 - What resources may be harmful to a beginner? Anything having to do with the names Matt Wright, or Selena Sol. Why? You may ask yourself. Well, their scripts are old and have been known to be buggy, as well as have security issues. They were written in the days of Perl 4. This means there is no scoping, stricture, warnings, idioms,
Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
> The current incarnation of my script blows itself out of the water if the
> $user_body variable (the TEXTAREA source) is greater than 4K, for example.
> This is good.
>
> I would like to be able to capture and control the process so that I don't
> get rudely blown out of the water with a crude 500 Server message (this
> would be gooder! ). I would like to: a)generate a useful message and, b)
> set some flags, do some more processing, and send a message back to the user
> to give them an opportunity to correct their input and atone for their sins.
> (This would be more gooder! )
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page->header;
$run = $page->param('RUN');
if (!$run && cgi_error()) {
# do whatever you do for an error
&dieWell ("413: Max Posting surpassed.");
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print "$thanks_for_playing_message\n";
# do logging of $message if you want, send yourself email, whatever
&footer; # end my html -
exit;
}
Lisa Wolfisch Nyman <[EMAIL PROTECTED]> IT Warrior Princess
"Life is too short to wear ugly underwear."
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: File upload problems still!
At 17:31 23/08/01, Ryan wrote: >^M's galore. The 'auto' setting on WS_ftp must not do much. By default WS_ftp will only be expecting files with certain extensions (eg. .txt, .htm) to be ASCII. So 'auto' will upload your .cgi or .pl files as binary. You can change these defaults on the Options button, Extensions tab. (I thought it was worth posting this response to the list, because I've had a few people puzzled by this in the past.) best, Mo Mo Holkar Undying King Games [EMAIL PROTECTED] http://www.ukg.co.uk -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: File upload problems still!
> >cat -vet script.cgi | more > ^M's galore. The 'auto' setting on WS_ftp must not do much. >in-place edit: > >perl -pi -e 's/\r//g' script.cgi > >Just make sure to back up your script, first. worked like a charm, eliminating all the ^M's When I tried it out, the program still crashed. It executes most of the code, up to the (paraphrased) $file = $cgi->get_upload(blah) then stops executing. I think maybe I can do something with .htaccess files to adjust the limit on PUT, but that is a bit too OT for here, I think. Thanks, Ryan -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CGI::POST_MAX use and control
Hi all,
I would appreciate some guidance in the use of CGI::POST_MAX. I've listed a
snippet of relevant code below from my program to illustrate.
When reading in data fields from an HTML form, I want to limit the size of
the data accepted from a TEXTAREA box. I don't want to depend upon my ISPs
timeouts and what-nots to stop a user from trying a DDOS on 'em.
The current incarnation of my script blows itself out of the water if the
$user_body variable (the TEXTAREA source) is greater than 4K, for example.
This is good.
I would like to be able to capture and control the process so that I don't
get rudely blown out of the water with a crude 500 Server message (this
would be gooder! ). I would like to: a)generate a useful message and, b)
set some flags, do some more processing, and send a message back to the user
to give them an opportunity to correct their input and atone for their sins.
(This would be more gooder! )
I've read through the CGI.pm writeup, but I don't believe I'm applying it
correctly. I am having a problem understanding just how and where to make
use of CGI::POST_MAX, CGI::Carp, and probably cgi_error() in my code. Where
do I put 'em and can someone demonstrate with a similar snippet of code just
how and where these are used? For example, when this bombs with data > 4096
bytes, I don't even see an error message in my error log file,
...cgi-log.txt -- that would be a nice diagnostic help, too.
If there is another prefered method to limit size of input, I would
appreciate learning about that, too!
Right now my code produces an 'accurate' result (a nuke will 'accurately'
kill a fly), but I would prefer to have it produce a 'precise' result
(perhaps a HOW-TO on using tightly focused gamma rays to zap that fly,
instead). It works, but its not elegant.
I'm looking for the state of "most goodliness".
(My apologies to non-native English readers of this list for my having fun
with the language, but its been a tough day...)
Thanks, all.
John--
[EMAIL PROTECTED]
===
#!/usr/bin/perl
use strict;
#use diagnostics;
use CGI qw/:standard/;
use CGI::Carp qw/fatalsToBrowser/;
BEGIN {
use CGI::Carp qw(carpout);
open(LOG, ">>$ENV{DOCUMENT_ROOT}/data/cgi-log.txt") or
die("Unable to open $ENV{DOCUMENT_ROOT}/data/cgi-log.txt: $!\n");
carpout(LOG);
}
$CGI::POST_MAX = 1024 * 4; ## Max 4K post size
$CGI::DISABLE_UPLOADS = 1; ## Disable file uploads
$formin = new CGI;
$user_name = ' ';
$user_addr = ' ';
$user_to = ' ';
$user_subj = ' ';
$user_body = ' ';
$user_name = $formin->param('name');
$user_addr = $formin->param('from');
$user_to = $formin->param('to');
$user_subj = $formin->param('subject');
$user_body = $formin->param('body');
## If good form data
## process the form's input...and do good things...
## else
## create return HTML page and tell user where they've transgressed...
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload problems still!
--- Ryan Davis <[EMAIL PROTECTED]> wrote: > Curtis+List, > > I checked out the CGI::Safe.pm module, and so far, I'm having the same > problem. The script goes to "Just about to get your resume!"; then quits. > I don't have access to server logs, so I don't know what is going on. I > think my server is running Apache, and I've been snooping to try and find > the config files (I got a >find / -name httpd.conf going right now) > > Is there anything perlish wrong here? It works on Activestate/Apache/Win98, > so I think it must be a server thing, but I dunno. What do you mean by "then quits"? Does it silently fail? Does it hang? Does it return an error message? Wild guess: Recently (like, two days ago), I had a problem with a script that worked fine on a Windows box but then mysteriously 'hung' on a Linux box. It was caused by the same problem that I had for my recent question about my script dying when I turned off warnings: Windows and Unix have different line endings. Since you mentioned that you had successfully run this on a Win98 box, I'm wondering if this is the problem. Windows recognizes \12\15 as the end of line characters (\r\n). Unix is looking for a \15 (\n). If you have shell access to your server, enter the following: cat -vet script.cgi | more This will display the end of line characters as a dollar sign. If you see a ^M before the dollar sign, then you know you have DOS line endings. Here's an example: #!/usr/bin/perl -wT^M$ If you see that ^M, (ctrl-M, a.k.a. ASCII 12, a.k.a. \r), you can eliminate it with the following in-place edit: perl -pi -e 's/\r//g' script.cgi Just make sure to back up your script, first. To prevent this in the future, make sure you FTP your scripts to the server in ASCII mode, not binary. ASCII mode will fix the line endings for you. If this doesn't resolve the problem, let us know. Cheers, Curtis Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: File upload problems still!
>Roger C Haslock wrote: >> >> Just an aside, but what is the point of format => 'Application/msword' ? >> >> Anyone can rename their file to look like '*.doc', and you can only >> determine the file content when you have uploaded it ( at which point you >> SHOULD check). > >not to mention you may offend those non-micro$oft users whose resumes >are plain text. > In the end, they are going to put on a resume CD, with a VB front end, and Word is used to do keyword searches, and about 100% of the population involved have their resumes in word anyway. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: File upload problems still!
>Roger C Haslock wrote: >> >> Just an aside, but what is the point of format => 'Application/msword' ? >> >> Anyone can rename their file to look like '*.doc', and you can only >> determine the file content when you have uploaded it ( at which point you >> SHOULD check). > >not to mention you may offend those non-micro$oft users whose resumes >are plain text. > In the end, they are going to put on a resume CD, with a VB front end, and Word is used to do keyword searches, and about 100% of the population involved have their resumes in word anyway. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload problems still!
Roger C Haslock wrote: > > Just an aside, but what is the point of format => 'Application/msword' ? > > Anyone can rename their file to look like '*.doc', and you can only > determine the file content when you have uploaded it ( at which point you > SHOULD check). not to mention you may offend those non-micro$oft users whose resumes are plain text. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload problems still!
Just an aside, but what is the point of format => 'Application/msword' ?
Anyone can rename their file to look like '*.doc', and you can only
determine the file content when you have uploaded it ( at which point you
SHOULD check).
Regards
- Roger -
- Original Message -
From: "Ryan Davis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 4:27 AM
Subject: File upload problems still!
> Curtis+List,
>
> I checked out the CGI::Safe.pm module, and so far, I'm having the same
> problem. The script goes to "Just about to get your resume!"; then quits.
> I don't have access to server logs, so I don't know what is going on. I
> think my server is running Apache, and I've been snooping to try and find
> the config files (I got a >find / -name httpd.conf going right now)
>
> Is there anything perlish wrong here? It works on
Activestate/Apache/Win98,
> so I think it must be a server thing, but I dunno.
>
> Here are the relevant snippets:
>
>
> use CGI::Safe;
> my $cgi = CGI::Safe->new( DISABLE_UPLOADS => 0,
> POST_MAX => 100 * 1024 );
> ...
> print $cgi->filefield('resume','starting value',40,180);
> ...
> print "Just about to get your resume!";
> # only allow Word docs
> my $file = $cgi->get_upload( file_name => 'resume', format =>
> 'Application/msword' );
>
> if ( $file->{ error } ) {
>print "Your file was not uploaded. Sorry."
> }
> print "Just got your resume!";
>
>
> This is getting a little OT, but my find was successful, and I think this
> applies to me:
>
>
> Options Includes Indexes FollowSymLinks ExecCGI
> AllowOverride AuthConfig Limit FileInfo
>
>
> Ok, after looking at Apache docs for 20mins, I can do an .htaccess file to
> control that directory, but I'm going to send this, just in case anyone
can
> make any sense of it.
>
> Any help would be much appreciated!
>
> Thanks,
> Ryan
>
> Sorry this is so rambling, it was written over the course of about an
hour.
> I'll be better about my future questions!
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
