Forms on UNIX server

Forms on UNIX server (Full Version)

All Forums >> [Web Development] >> Server Issues

Message

qwerty -> Forms on UNIX server (12/31/2001 12:57:29)
I have an FP2k site hosted by my ISP on a UNIX server, and we've noticed something odd about our forms, which are set to both email my sales department and append a web page in our /_private directory: according to the ISP's CGI error logs, an error like this is generated every time the form is successfully submitted: 12/28/01 11:05 "/web/_vti_bin/shtml.exe", proc "sendmail -oi sales@psipay.com": sendmail: using default from-id of 'webmaster' Now, that's fairly irritating, but not really a big deal, as long as it works. Well, today I received an email from a potential customer who says that he's tried to fill out my form twice and gotten a 404 error both times. Here's the big deal: there was no error generated on the CGI error log. Seems it only posts an error when it works. I have no way of knowing how many times this thing has failed on me. I've spoken to my ISP, and they say the problem is with FrontPage, and I should contact MS, so I thought I'd try you folks first. The form in question is at http://www.psipay.com/InfoRequest.htm, by the way. Thanks.

caywind -> RE: Forms on UNIX server (12/31/2001 14:40:24)
OK, upon succesful submission of the form, the script fires off an e-mail to an account sales@.... Since the mail accounts don't match?? an error message is logged and the mail is sent to the default maildrop??? 2. quote: today I received an email from a potential customer who says that he's tried to fill out my form twice and gotten a 404 error both times lot of x-factors here. let me check... All this to change a number into a name...

ginnie -> RE: Forms on UNIX server (12/31/2001 14:49:02)
I tried your form and it worked fine, bringing up your custom confirmation page. When is your client receiving the 404 error? (404 means the file can't be found) Is it when clicking on a link to get to the form, or after submitting the form and looking for the confirmation? I couldn't find any links to the form on your site, (but it's possible I overlooked it). ginnie Global Presence Web Design

qwerty -> RE: Forms on UNIX server (12/31/2001 14:57:11)
The customer wasn't very specific about where he got the error, but I'm assuming it was after hitting the submit button. The reason you didn't see any links to the form is that I've removed them until I figure out what's causing the problem. There is a button at the upper-right corner of each page labeled "Request Information". That used to link to the form, but for the time being I have it generating an email message to the sales address. I suppose it's possible that the problem was at the customer's end, but I'm concerned that no error was generated at the ISP. It has me worried that a lot of people have been getting this error, and this guy is the only one who bothered to tell me about it.

caywind -> RE: Forms on UNIX server (12/31/2001 15:03:14)
I looked through the code...can't really see anything there...is it possible is could be a cache or timeout issue... All this to change a number into a name...

caywind -> RE: Forms on UNIX server (12/31/2001 15:11:58)
did the location or content of the form page change recently? If it looked for the old confirm address after submission of an old copy of the form... All this to change a number into a name...

qwerty -> RE: Forms on UNIX server (12/31/2001 15:17:35)
The content changed slightly a month or two back, but since I don't know whether the error reported to me is a common one, or whether it's happened before at all, I don't know when the problem first appeared. If it's any help, I can tell you that the email address, the URL of the confirmation page and that of the private page to which the results are written have not changed at all.

caywind -> RE: Forms on UNIX server (12/31/2001 15:30:23)
probably not cache, timeout, or ISP problem. I just accessed the page using the dino-MAC, worked fine. All this to change a number into a name...

qwerty -> RE: Forms on UNIX server (1/16/2002 11:08:11)
I have a fascinating update to this issue. I'm not sure if I'd be better off posting it as a new topic, but here goes: after a pile of calls and emails to my host (XO, by the way), they gave me what they considered to be the final word: they support a lot of FP server extensions on their UNIX servers, but not all. They do not support FP forms. They offered to switch me over to one of their Windows servers (which they refer to as both Windows 2000 and NT at various times), where they guarantee full support of all FP server extensions. I asked a few questions about whether we'd lose anything we currently have in order to make the change, they told me there was nothing to worry about (the non-supported stuff was all things we don't use), and we switched over. A few days later, I noticed that my custom 404 page was not displaying. Instead, I was getting the standard IE "file cannot be found" page. I called up support, and guess what? They don't support custom 404s on their Windows servers. I asked why, and they said it can't be done. So I went to TechNet, found the instructions on pointing IIS 5.0 to a custom error page, sent it on to them (it's something like a 3-click process) and asked them to give it a try. They wrote back to say that it can't be done. I asked why, and they simply continue to say that it's impossible. Has anyone else experienced this kind of nonsense? I have to assume that these people know a little more about the technology involved than I do, so it's possible that they're telling the truth. But if that's the case, all I'm really asking of them is a real explanation as to why it can't be done, but they refuse to even give me that. I've spent a few hours today talking to someone in their sales department, explaining that they're going to lose a lot of clients over something like this if they won't give an explanation of why they are unable to provide what I consider to be a very basic service. I think the time has come to start looking for a new host.

ginnie -> RE: Forms on UNIX server (1/16/2002 11:19:09)
>>I think the time has come to start looking for a new host. You're right. It sounds like they don't know what they're doing. Form handling is one of the most basic features of FrontPage extensions. If you don't have that, you don't have FP extensions as far as I'm concerned. ginnie Global Presence Web Design

Gil -> RE: Forms on UNIX server (1/16/2002 13:43:06)
Remember, when a System Admin says, "It can't be done" or "It's not possible" - most of the time what they are really saying is "It's too much trouble". Now, in their defense - doing anything (like custon error pages, etc.) on a Windows server is a lot more complicated and time consuming than on a Unix server. Gil Harvey The Host Factory Resellers are our Specialty Find a Web Professional

qwerty -> RE: Forms on UNIX server (1/16/2002 15:03:25)
I know it's only a one-line script in UNIX, but the instructions I found for setting it up on IIS aren't much more complicated than that: 1. In the Internet Information Services snap-in, select the Web site, virtual directory, directory, or file you would like to customize HTTP errors, and then click Properties. 2. Select Custom Errors. 3. Select the HTTP error that you would like to change, in this case 404. 4. Click Edit Properties. 5. Select File from the drop-down list. 6. Enter the full path that points to your customized error message, or use Browse... to locate the file on your computer's hard disk. 7. Click OK. Doesn't seem too rough to me. And I checked with ViaNet.Works, and they tell me they can do it for a one-time fee of $20.

Gil -> RE: Forms on UNIX server (1/16/2002 16:58:05)
quote: And I checked with ViaNet.Works, and they tell me they can do it for a one-time fee of $20. Hmmm, I guess having a place to do it on our control panel means we are losing money Gil Harvey The Host Factory Resellers are our Specialty Find a Web Professional Edited by - Gil on 01/16/2002 21:34:46

Page: [1]

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

8.203125E-02