On Wed, May 30, 2007 9:16 pm, Daniel Kasak wrote: > On Wed, 2007-05-30 at 13:40 -0500, Richard Lynch wrote: > >> On Tue, May 29, 2007 6:37 pm, Daniel Kasak wrote: >> > Actually, that blog had absolutely nothing to do with my problem >> > ( thanks for RTFP!). Not only that, but the recommendation that I >> > construct URLs: >> > >> > http://address.com/script/thing=2/this=3/that=4/download.txt >> > >> > is patently ridiculous. >> >> Why? > > It's excessively complex for no actual benefit. It means you have to > have extra code to 'explode' out the various parts of the URL. Even > after reading your description of the code that handles this, it was > non-obvious what it was for. If I returned to this 2 years later ( or > God forbid, someone else had to look at it ), they wouldn't have a > clue > what it was doing, or why. But also, as I noted, this 'solution' is to > a > different problem - the problem of IE not naming downloads properly. > IE > names them properly for me ... it just doesn't download them ( if over > SSL ). Actually, it solves more than just IE not naming them properly. It also solves some versions of IE not opening PDF from FDF links when the user has chosen to not embed PDF reader in browser bug. It also solved a host of other IE bugs over the years. It would not surprise me in the least if it didn't solve your bug as well, actually. IE is just plain flaky with its stupid attempts to "guess" about content type and intent from URL analysis. I'm sorry you found a simple loop to look at the URL and pull the values into an array confusing... :-v TETO -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
