72 hours - ENOUGH IS ENOUGH

[heath]

The problem I had of weird parsing errors from a few months ago is back.

It has been happening for over 72 hours now, and I would greatly appreciate someone making this a priority.

I realize there is no "fix", but Justin and Terra "rolled" back my php version to either 014 or 015 before and it did the trick.

Evidently, something was done to NINE in the past 3 days to initiate this, and I would appreciate you guys getting it fixed.

The response I got via email was unsatisfactory, to say the least.

Heath

[Terra]

There was one minor patch done to the PHP3 daemon last night, but I do not see how this would have caused any catostrophic results...

The version patched, is the same one that we have been running since the last major upgrade (3.0.15)...[nbsp][nbsp]The problem fixed was the retainment of the 'sendmail_path' setting that is only handled during the Apache DIR/.htaccess merge...[nbsp][nbsp]This *had* to be fixed quickly as it was causing major inconvenience to users receiving erroneous bounced emails from other domains using the PHP3 mail function...

To carry forth, I will roll out a new PHP/3.0.16 that is currently being fitted for all servers...

Heath, currently only your domain is experiencing problems which leads me to believe this is an isolated problem...[nbsp][nbsp]You have to remember that the PHP3 core that drives your domain - also drives a thousand plus others, with many users that are just as heavy (if not heavier) than your usage...

I am not turning a deaf ear (nor a blind eye) to the problem report, but isolated incidents that are not easily reproduced, take time to find and fix...[nbsp][nbsp]The 'sendmail_path' problem took (high-priority) precedence to your problem report, and now that the work is completed on that I can now focus my radar to your situation...

--
Terra
--sysAdmin by day, sysAdmin by night--
FutureQuest
[This message has been edited by ccTech (edited 05-12-00@03:03 am)]

[Justin]

Hello Heath,

If you search our FAQ you will find this:

http://service.futurequest.net/tech/support/solution?11=000417-0025&130=955998926&14=4&2715=0&15=&27---16=&57=faq&58=

The end result is that you may have uploaded your files in Windows or Macintosh format without stripping carriage returns. Re-uploading your files in ASCII (or Text) mode will correct the problem...

This is a known PHP bug, however we do not have a fix - but the workaround is to upload your files in ASCII mode (which should be done anyway when running text files/scripts on a Unix system)...

I hope this helps...

[This message has been edited by Justin (edited 05-12-00@03:56 am)]

[Terra]

Ok, this thread is going to get real funky, real quick...

I had originally deleted Justin's post that was sandwiched between Heath's and my post...[nbsp][nbsp]After digging further (and *much deeper*) into the issue I have found Justin's response to be 100% correct...

Ok Heath, here is the scenario...

1) We upgraded PHP3 about 2 months ago from 3.0.12 to 3.0.15
2) This new version now requires you to upload your file in ASCII format (all linefeeds, no carriage returns) just like perl files
3) Due to your files being embedded with carriage returns, your PHP3 scripts broke...
4) After an extensive phone call with you, we agreed to apply PHP/3.0.12 only to your xip of .42
5) You agreed that this was a temporary solution and that you would work on getting your files straightened out by cleaning out the CRLF issues
6) Last night, PHP/3.0.12 was removed and replaced with PHP/3.0.15 with the neccessary 'sendmail_path' hot patch in place...

So, for the record:
1) It has not been broken for 72 hours
2) We will not hot patch PHP/3.0.12
3) All site owners on .42 will enjoy the new capabilities of PHP/3.0.15 instead of being forced to use Heath's older version of PHP/3.0.12
4) You will need to fix your files by bringing them into compliance with the new PHP3 version

I do not see how you can argue (or be hostile) with us, after we have afforded you ample enough time to fix your domain after explaining exactly what the problem was to begin with...

We can no longer hold back the PHP3 daemon on x42 for your exlusive use...[nbsp][nbsp]Please make the effort to bring your domain to compliance...[nbsp][nbsp]There will be no extensions of grace period given...

--
Andrew Gillespie
CTO/Systems Administrator
FutureQuest, Inc.

[Deb]

BTW -- For anyone on x42 (or any IP for that matter) using PHP the fix (in English) is to simply upload the files in ASCII (the same as you would a cgi script).[nbsp][nbsp]

If the files are already uploaded, but not in ASCII, there is a point and click way to strip the carriage returns from within your CNC as well as a tutorial at http://www.aota.net/Script_Installation_Tips/ascii.php3

Hope this helps to translate any of the tech's geek into English for the rest of us :)

Deb
[nbsp]- Simplicity can be so complicated.

[Dean B]

S'cuse me for butting in, but why on earth would you want to upload php files in binary ?[nbsp][nbsp]Php files are always text, aren't they ?[nbsp][nbsp]Adding php, php3 to the text file extensions in your FTP program, thereby forcing ASCII upload, is something I always tell anybody that asks me about php.

Am I missing something here ?

Dean.

[heath]

MY FILES ARE NOT UPLOADED IN BINARY.

NOW WHAT?

I never agreed that the carriage returns were the problem a few months ago AND NEITHER DID YOU.

Also - I submitted several tech support queries because your goofy as all get out support desk kept bouncing my email.

I am begging you to do the right thing and quit blaming me for the problem --- please find a solution --- I've done 100% all I can from my end.

PEOPLE ARE COMING TO MY SITE AND SEEING THE TEXT OF OTHER VIRTUALLY HOSTED DOMAINS ON NINE -- some of the information sensitive.

This is a serious problem, and I would appreciate a halt to the pass the buck style of tech support that has become standard operating procedure at your organization.

Heath

[heath]

BTW -- For anyone on x42 (or any IP for that matter) using PHP the fix (in English) is to simply upload the files in ASCII (the same as you would a cgi script).[nbsp][nbsp]
Wrong.

5) You agreed that this was a temporary solution and that you would work on getting your files straightened out by cleaning out the CRLF issues
Wrong, since doing this with several of the files didn't change a thing.

You surmised, and I agreed that it was a memory problem on your servers.

All site owners on .42 will enjoy the new capabilities of PHP/3.0.15 instead of being forced to use Heath's older version of PHP/3.0.12
All site owners enjoy the capabilities of having their data exposed on my servers.

Everyone come read the sensitive data of all domains hosted on NINE.

www.thedailyspread.com (http://www.thedailyspread.com)

Heath

PS I believe your steadfast refusal to fix the problem, combined with the ramifications of the what is happening with other people's data is making you guilty of gross negligence and incompetence and I am asking for the last time to please patch me back to the old version of php, or fix sendmail, or call on the Holy Spirit, or do whatever it takes to resolve this issue.

[JoeRT]

I tried a few times by using the URL he provided... never saw anyone else's site or any sensitive data.[nbsp][nbsp]Then I figured it was just incrementing his hit counter, so I stopped.

[heath]

I tried a few times by using the URL he provided... never saw anyone else's site or any sensitive data.[nbsp][nbsp]Then I figured it was just incrementing his hit counter, so I stopped.
I was asked to remove a post before where I quoted some of the text that was being parsed on my site from another's mental health forum.

The problems are random, and usually its just a wierd include error.

Often, though you'll see others path info in my include error - in[nbsp][nbsp]many cases text from the UBB of other people's domains.

My error logs are an especially interesting read.

Heath, currently only your domain is experiencing problems which leads me to believe this is an isolated problem...
Isolated to my domain, yes - but its everyone's problem because the data from other sites is being spit out in my error messages for the world to see.

I'm just waiting for the database passwords to be sent to the browser, or God knows what else.

If anyone thinks this is "isolated", they are very naive.[nbsp][nbsp]My domain, yes - but others data.

It has not been broken for 72 hours
I guess technically, its been broken for 3 months.

We will not hot patch PHP/3.0.12
I am asking you to reconsider this.

4) You will need to fix your files by bringing them into compliance with the new PHP3 version

Save a few files from the first time this occurred, all my files are in "compliance".

Now that I have manually checked every file on my site, and the problem persists, could you please do address it and stop pointing the finger?

I do not see how you can argue (or be hostile) with us, after we have afforded you ample enough time to fix your domain after explaining exactly what the problem was to begin with...
I am not being hostile.

1.[nbsp][nbsp]The problem as either Terra or Justin said, was a memory leak from your HACKED HOMEGROWN APACHE CORE.

2.[nbsp][nbsp]I did everything I was told to do in order to "fix" this, and it didn't work -- perhaps because you are misinformed about the problem?

My hostility arose when you folks said "its your fault, you deal with it.[nbsp][nbsp]Quit sending us email".

Heath

[This message has been edited by heath (edited 05-12-00@2:14 pm)]

[DB]

FWIW, the first time I tried to enter the site I received an error, upon reloading, the index page displayed except for all the banners being displayed by the ".../phpads/phpAds/viewbanner.php3" script. Attempting to open a banner in a new window resulted in the following error:

Fatal error: Failed opening required '
R 4ÌR t R Œ•,R ,DR œ•PR d^R
kR DÐ~R  ,' in /big/dom/xthedailyspread/www/phpads/phpAds/viewbanner.php3 on line 198

Other pages were the same, most of the banner graphics weren't displayed, through there were a few exceptions. I didn't see any "sensitive data."

Heath, I really hope this problem gets resolved soon, I know how frustrating it can be.[nbsp][nbsp]I had a simple counter CGI that refused to work for me one day. At first I suspected the server, so I tried it on another account located on a different FQ server and it worked. I could see absolutely nothing wrong with the broken script and was about to open a tech support ticket when I decided to try one more time, from scratch. I did everything exactly the same as the first time only this time it worked. I don't know where the glitch came from, maybe it was an errant CR that wasn't stripped out. I can't offer you much in the way of tech support, only some moral support... we've all run into these situations. Since the problem does appear to be localized, maybe someone will allow you to set-up a few scripts on a different server and see what happens... simple process of elimination.

------------------
--Tom aka DiamondBack
[nbsp][nbsp]http://diamond-back.com
[nbsp][nbsp]http://smartasses.org

[heath]

I can't offer you much in the way of tech support, only some moral support...
I appreciate the moral support.[nbsp][nbsp]Its infinitely more than FQ has bothered to offer.

Even the tech support you offered in the above is more helpful to me than the online faqs and the replies from Justin and Terra and Andrew.[nbsp][nbsp]

The "sensitive" data I alluded to is not as bad as it was before, and only seems to happen 10% of the time.

Most of the data, I guess isn't "sensitive" at all -- its things like the text from other domain's UBB formums, or even the path info from someone else site.

Anyone with a domain on NINE should be concerned about their path info and data being spit out on someone else's domain.

The customers of FQ should equally be upset that the tech support people have twiddled their collective thumbs, and steadfastedly refused to acknowledge the problem as anything but "isolated", and have furthermore REFUSED to implement the simple fix of patching my php to an older version.

This is GROSS NEGLIGENCE, in my opinion - pure and simple --

I have always sung the praises of FQ and their tech support team.

However, the level of importance this problem has received from FQ should alarm every single site owner being hosted at here.

I am not hallucinating these problems.

90% of the include errors on my site don't deal with other people's info.

But 10% do, and this is not good.

I will be more than happy to start posting my error logs if this is what it takes for an uprising and for this problem to receive its due diligence.

Heath

Anyone that thinks this problem doesn't concern them is just naive.

[Deb]

Heath,[nbsp][nbsp]I can tell you the incident is *not* closed.[nbsp][nbsp]Andrew is still pondering what is happening on your account and is still trying to pinpoint what may be causing it.[nbsp][nbsp]He in no way is ignoring your request.[nbsp][nbsp]With this situation starting up again with you yesterday.

Please allow him time to work through it.[nbsp][nbsp]Since it is only your account at this time the most he can do is work through all of your files to see if he can find the culprit.[nbsp][nbsp]These things are not fixable overnight.[nbsp][nbsp]And since they are not Andrew's scripts it takes longer to troubleshoot them as he must read the contents of every file.

Deb
[nbsp]- Where would you like the Sys Admin Today?

[Terra]

Ok Heath, I have painstakingly scanned **everyones** error log looking for the 'PHP 3 Fatal' in regards to includes...

thedailyspread.com is the *only* domain that is exhibiting this problem and it appears to be isolated to the php3ad software that you run...

You are running deep includes, and from the _normal_ errors you generate, pretty much push PHP3 to the limits...

Once again, I have applied the bandaid fix of PHP/3.0.12 to x42, but be warned that I will switch this in and out at any time because I cannot isolate/fix what I cannot reproduce...[nbsp][nbsp]Since this is only your domain having the problems, I cannot test this anywhere else...

I am not sure what is triggering this problem, but you have so *much* stuff going on that I don't even know where to begin...[nbsp][nbsp]You are pulling so much information from other peoples domains ( URL fopens() ) coupled with the fact that you pound the living daylights out of the MySQL servers, that troubleshooting your domain is by no means a trivial prospect...

I would ask that you go through the php3ad software, with a fine tooth comb - and for anyone else reading this thread that runs php3ad, please let us know if you are experiencing the same kind of 'include' problems...

--
Terra
--The needs of the many versus the needs of the one can be the epitomy of the razors edge--
FutureQuest

[heath]

Terra --

Thanks for applying the bandaid.

You have my word that I will do everything in my power to to correct the problem during this time, including the re-installation/upgrade of phpads.

To be honest, there isn't "a lot going on" on my site.

Do I use includes on every page for footers/headers, etc? -- yes.

Do I pull news feeds via ftp and tcp and use mod_rewrite: yes

However, all of these things aren't going on at once, and they aren't going on in every page of my site, and things like mod_rewrite are used sparingly.

However, the simplist:

<code>
<?
print &quot;hello world!&quot;;
?>
</code>

produces errors.

I still think the problem has to do with my .htaccess file using addtype to parse html as php.

I also intend to implement a version of the Cached Modules at phpbuilder to reduce the whacks to mysql.

I don't think any of these changes will have an effect on the problem - especially if its in the .htaccess file as I suspect, but in deference to your request I'll do it and we hopefully won't have to go through this again.

Thanks for patching my domain back to the older version of php.

Heath

[Terra]

I can honestly say: &quot;Never a dull moment at FutureQuest&quot;... ;)

--
Terra
--Hey Boss, remember that vacation you keep promising me???--
FutureQuest

[Deb]

Battlefield Earth begins at the local theater at 9:40pm tonight.[nbsp][nbsp]Wanna go on a two hour vacation?

Deb
[nbsp]- Boss? Heh, only in the homelife :P

[Stephen]

OK, my interest is piqued. Where can we go to see the sensitive data? Exact URLs only please...

[Terra]

Heath, I have just updated x42 to:

Apache/1.3.12
PHP/3.0.16

I believe the problem was using PHP3 as a DSO module and somewhere during the .htaccess merging something had gotten crosswired...[nbsp][nbsp]From what I can tell, you have somehow triggered an extremely obscure bug...[nbsp][nbsp]This most likely started to happen after PHP/3.0.12 as they became extremely aggressive in their memory optimations/usage...

Let me know if you experience any further problems...[nbsp][nbsp]If everything goes well, I will go ahead and upgrade the entire server to this new combo...

I figure if it can pass by your domain standards, then darnit - it must be good for everyone else as well...[nbsp][nbsp]:þ

--
Terra
--Battfield Earth, just leave your brain at home and you will enjoy the flick--
FutureQuest

[Terra]

Arrrgghhhhh!

It did not work... :(

I have been reloading your main page and also freepicks...[nbsp][nbsp]It was off to a great start, but the weird includes started happening again with php3ads (viewbanner.php3)...

Please, upgrade the entire php3ad system that you use so I can rule this out...[nbsp][nbsp]From here, isolation of this problem goes down to the ltrace and strace level...[nbsp][nbsp]For those that know, you need to run Apache with '-X' (single user/no spawn) mode to try and fish out a glimpse of the cause...[nbsp][nbsp]In other words, this will get very deep, very quick...

Before I pull out those guns, upgrade your php3ad (by Sunday if possible) and I will try the new combination again...

To be quite frank, I am running a plain-jane no frills Apache/PHP3 on your domain right now (nothing special with 0 optimizations)...

For now, I am shifting back in the old versions and calling it a night...

--
Terra
--010--
FutureQuest

[heath]

Terra ---

Thanks for giving it a shot.

I am using a magic quotes directive in my main .htaccess per the phpads docs - do you think this has something to do with it?

I will upgrade to the latest phpads by Sunday, May 14th.

Thanks again for devoting the time to this, and I apologize wholeheartedly if I ever got out of line.

Heath

[Carlos]

I'm not sure this can help but I use PHPads too and I've been subscribed to their mailing list for a while. There are a number of known bugs in phpads, and some of them have not been fixed even in the last version (1.4). I saw one thread about a problem with view.inc.php3 that looked similar to the problem you've been discusing here. One of the messages says:

&quot;I have a weird problem with the view function ....

I've uploaded from 1.3 to 1.4 and everything seemed to work ok, but then
suddenly the pages didn't show properly, blocking themselves while loading
to a certain amount of the page header ... a little about the loading of the
view function ...&quot;

I think the problem is in phpads itself and the bug maybe arises only with some versions of php.

Hope this help you.

[heath]

Personally, I think blaming phpads for my problems is like blaming the price of tea in China on John Rocker -- simple pages that don't even use phpAds were giving problems.

In any event, I updated to the latest version to see if changes anything.

Thanks for the info.

Heath

[frankc]

The home page loads just fine now, whereas on the 12th or 13th it just gave errors...

[nbsp][nbsp]Frank

[Terra]

Heath, I need for you to clean up the following files that result from this command (162 files I count thus far):


$cd /big/dom/xthedailyspread/www
$find ./ -type f -print0 | xargs -0 perl -ne 'if (/\r/) {print &quot;$ARGV\n&quot; if $ARGV !~ /\.gif|\.jpg|\.bmp$/;}' | uniq | less
**or replace '| less' with '> myoutfile.txt' if you want that instead


This will show you all of your files that contain embedded Carriage Returns (\r)...[nbsp][nbsp]These \r will cause PHP3 to not parse your files correctly and cause random errors like you've shown...

I have excluded the image files from the list, but I'm sure there may be extraneous files like .gz tossed in...[nbsp][nbsp]Basically, anything that will be parsed by PHP3 needs to be cleaned up...

You may also want to run the above command in your 'cgi-bin' as well...[nbsp][nbsp];)

Hope this helps in taking another step forward on normalizing your domain and bringing it to the newer PHP3 requirements...

BTW: We need to clear this up as soon as possible in preparation for PHP4, because once this is in place PHP/3.0.12 will be completely dropped...[nbsp][nbsp]It would be an enormous waste of memory to be running 3 separate instances of PHP...

--
Terra
--I'm running outta water here--
FutureQuest

[Justin]

Also keep in mind that some of your files are in Mac format, which means lines are terminated *only* with a CR and no LF. This means that if you simply strip CRs from your files, you would be left with *no line terminators*. In other words, the entire script would be on one line.

The CNC handles this properly, however - but the command line alias 'stripcr' will simply remove the CRs all together.

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

[mike_w]

I find it rather extraordinary that the FQ staff would ever bother to try and debug a customers code. Seriously, your getting the service of programmers, for free. Having had about 30-40 isp's and hosting providers in the past I have never seen this done before. Anywhere else, if you were the only one having a particular problem with your site you would be SOL and on your own.

[heath]

The CNC handles this properly, however - but the command line alias 'stripcr' will simply remove the CRs all together.
I ran this on every file in my site that is in use when the problem first came up.

Heath, I need for you to clean up the following files that result from this command (162 files I count thus far):
162 in binary mode?[nbsp][nbsp]I don't know how.[nbsp][nbsp]I stripped the files when the problem first came up.[nbsp][nbsp]

There may be ancient files no longer in use, but I don't know how they could be causing the problem.

I will run your shell script anyway - thanks.

Also - can I get a backup of my old mysql database?[nbsp][nbsp]I was told I would be warned before it was deleted -- (I emailed tech support saying I wasn't done with the conversion yet, and they told me I would be warned before it was whacked).

Thanks.

[Justin]

Email History:

3/2/2000 - Heath requests six databases on new MySQL server, and they are set up. He is notified that he has seven days to move his data.

3/8/2000 - Heath notes that 7 days is quite short, asks for extention.

3/8/2000 - Heath is notified that we will let him know ahead of time, and that he should let us know when he is finished moving his data.

3/22/2000 - Heath states that he will be done moving his data in about 48 hours.

5/17/2000 - After more than 2 months, the data has been cleaned out.

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

[Deb]

Heath,

I am going to have to ask that you submit your requests one-time only in one form or another.[nbsp][nbsp]Responding to them via email and the forums uses valuable time by multiple techs that could be better utilized in other areas.[nbsp][nbsp]

Whether you use the forums or email is up to you (however specific account issues are better handled via email) but you do need to use only one or the other.[nbsp][nbsp]Multiple requests in multiple areas is considered an abuse on the resources available.

Deb
[nbsp]- .

[heath]

---------------
Email History:

3/2/2000 - Heath requests six databases on new MySQL server, and they are set up. He is
notified that he has seven days to move his data.

3/8/2000 - Heath notes that 7 days is quite short, asks for extention.

3/8/2000 - Heath is notified that we will let him know ahead of time, and that he should let us
know when he is finished moving his data.

3/22/2000 - Heath states that he will be done moving his data in about 48 hours.

5/17/2000 - After more than 2 months, the data has been cleaned out.
You forgot:

3/22/2000 - FQ states &quot;no problem&quot; and RESTATES their policy of ALWAYS letting a user know before their data is purged since offering multiple mysql databases is a new feature.

Heath

[heath]

Multiple requests in multiple areas is considered an abuse on the resources available.
I am guilty as charged here, simply because I rec'd yet another slew of bounced messages, informing me to &quot;post between the lines&quot;.

I have no idea if you are seeing the bounced messages or not, so I simply restated my request here in the forums to have the db restored since I was also instructed NOT to reply directly to &quot;support@futurequest.net&quot;, but to reply to the god-forsaken &quot;incident report&quot; message (which wastes my time and resources since I'm too stupid to figure out how to post my reply &quot;between the lines&quot;.

As a believer in God-given free will, if you would no longer prefer to have me as a customer, I understand - just tell me.[nbsp][nbsp]You don't owe me any service, even if I'm willing to pay for it -- anymore than the McDonalds down the street owes me a hamburger just because I've got a a buck thrity-five.

I'm a little slow, so I may never get the hint -- might oughta just speak your mind and make it easier on all of us.

Heath

[Drew]

Pardon me for making light of a very ugly situation, but this is better than TV ;)[nbsp][nbsp] I won't say whose side I'm on just to be diplomatic, but my best to ending the situation... and more importantly, ending the bickering ;)

Drew

[Deb]

Heath, are you sure the replies you are receiving aren't the confirmation noting we have received the requests?[nbsp][nbsp]We get a log of every instance... those not between the lines just let us know the date/time someone made the attempt and those between the lines obviously contain the text of the message.[nbsp][nbsp]On your request concerning this issue it was received and a confirmation was automatically sent back to you.[nbsp][nbsp]Within minutes a reply from us was sent out and again within minutes your response to that reply and again our response to that etc etc...

I do not show any record of a bounce in that communication and your replies were showing as they should be...[nbsp][nbsp]Again, the web based form will also allow you to avoid the &quot;between the lines&quot; rule.

You as a site owner on the servers is more than fine as long as the services are suiting your needs.[nbsp][nbsp]If we can not provide your needs then it obviously is not productive for either party ... but if we can work together and your needs are being met by all means that's the goal.

The key is working together... this rings true for everyone.[nbsp][nbsp]There are limits as to what we can and cannot offer. If those limits are too low for your requirements then it's best to find someone who can meet them.[nbsp][nbsp]My main concern at this point is the hostility.[nbsp][nbsp]We are trying to service you but seem to be failing at satisfying your requests.[nbsp][nbsp]If we continue to fail in that area then yes, I would think it best for you to find a host that can succeed.[nbsp][nbsp]If on the other hand, we do reach satisfaction by all means stick around.

Deb
[nbsp]- One #9 SuperSized Please.

[Jacob Stetser]

I don't know if this is related, but all of a sudden I'm getting some spurious errors on http://sandbox.icongarden.com/robots/jump.php3 ... every so often it decides not to load with an include error - and every so often it's different.

I went and checked to see if I was on .42 like Heath, but I'm not. The weird thing is, this just started happening after the issue was being looked into by Terra, and I haven't edited that script in several weeks.

Just thought I'd bring it up.. anyone got any ideas?
------------------
icongarden.com/?fq (http://icongarden.com/?fq)
icongarden: making good ideas grow.

[Justin]

Make absolutely sure that there are no carriage returns in the script (as well as any include files) - make sure they were uploaded in ASCII/Text mode. The current PHP has problems with carriage returns, especially in Mac format (which terminates lines with *only* a CR and no LF)...

Hope this helps.

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

[Terra]

I have reset the x21 Apache, which seems to have cleared that PHP3 error...

I have continually reloaded the 'jump.php3' page, and do not see the problem anymore...

This is the second person to report a problem with PHP3, and both site owners use php3_ overrides in .htaccess files...[nbsp][nbsp]If this starts to spread much further, I will have no choice but to rip out all PHP/3.0.1[56] installations and move them back to PHP/3.0.12...[nbsp][nbsp]:(

What is truly odd, is that icongarden.com is on the SIX server, which has not changed in configuration for quite awhile...[nbsp][nbsp]I have also tested, and retested my php3_sendmail_path fix and I am 110% sure that was not the cause...

We do know one fact is sure, files that are parsed for php3 commands, which have embedded Carriage Returns, will cause these include/require problems...

Irregardless of this fact, I am still digging through the PHP3 source code to see if I can fix it myself since the PHP3 developers are giving me the cold-shoulder concerning this issue (they are too busy with PHP4)... :(

--
Terra
--Ever want to take a moment, and just go home?--
FutureQuest


[This message has been edited by ccTech (edited 05-18-00@5:00 pm)]

[Jacob Stetser]

Thanks for looking into the problem for me. I do appreciate your checking it. In the meantime, I'll poke into my .htaccess file and see if I'm doing anything out of the ordinary.

You're right that it's odd that it popped up all of a sudden. Perhaps it's been going on and I just haven't noticed until now. I'll definitely check for bad line endings in my code (I have everything here set to save in UNIX line endings, but sometimes stuff slips by).

Thanks again!

Jake
------------------
icongarden.com/?fq (http://icongarden.com/?fq)
icongarden: making good ideas grow.

[PaulKroll]

I just couldn't help but go look at the jump.php3 troublemaking page: I reloaded, oh, three or four times, fine. Read a bit of the page. Then I hit reload again, once: &quot;Fatal error: Failed opening required '/big/dom/xicongarden/www/sandbox/robots/jump.php3 on line 1&quot;

Darn weird.

And as I was nearly finished with this message, I tried again, and THIS time I got 'ument' instead of the jump path... and then after a couple of tries, another failure with '401' instead of 'ument'... (all tries a few seconds apart, using IE5.01)

I fear I'm about to face similar problems as the site I'm putting together is going through internal testing... and it's currently set up to use php3_prepend in .htaccess (it's a phplib based site). I'm interested in anything I can do to help solve this problem before I have to deal with it in a pressure situation.

Can we get a rundown of the known conditions that are similar? You mentioned php3_ overrides in the .htaccess files: any other similarities?

And Terra, most important of all things you have to deal with: &quot;regardless&quot; is the word. &quot;Irregardless&quot; is not a word. :)

[PaulKroll]

And for the sake of oddity, I tried hitting jump.php instead of jump.php3:

&quot;The requested URL /robots/jump.php was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.&quot;

And trying jump.php3 (again, a retry every few seconds, not an all out assault) is getting me 'ErrorDocument' and bad characters (I'm in windows right now, and don't have an editor that'll tell me what chars), either four of them, or one of them. This was all about 20 minutes ago (it's now 1:12 am Chicago time, and I've really gotta go sleep... )

Does it matter if the .htaccess document has null characters or MSDOS/Windows CR/LF line terminators?

[Justin]

The odd characters would not be a direct result of the contents of the .htaccess file... If there were invalid characters in that file, you would simply get a 500 error (and consistantly).

The problem is an obscure PHP bug that seems to have started with the 3.0.14 release. The particular bug at first only surfaced within files that contained carriage returns.

Normally, PHP doesn't care about carriage returns - it is a cross-platform scripting language, and carriage returns, line feeds, or any white space would make no difference. In fact, Perl is content with carriage returns - it is Linux that causes the 500 errors for a binary-uploaded Perl (or any CGI) script.

The latest 3.x PHP versions, however, behave oddly when a script has any carriage returns. I'm not sure what they changed, but it seems to surface when:

a) File has carriage returns
b) You are using any .htaccess overrides for PHP (regardless of what they are for)

It seems to be a combination of the above... the errors are random and inconsistant, which leads one to believe that PHP is improperly handling a variable or pointer... Either way, it is documented (http://service.futurequest.net/tech/support/solution?11=000417-0025&amp;130=955998926&amp;14=4&amp;2715=0&amp;1-5=&amp;2716=&amp;57=faq&amp;58=) in our Service Desk (http://service.futurequest.net), as it is a known issue...

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

[Deb]

Merging the issues to continue please view:
http://www.aota.net/ubb/Forum4/HTML/000371-1.html