Re: Net_URL Bug #6470

I'm not really sure what you are talking about here. My guess is that you're pointing to parse_url not being able to properly parse urls. So you suggest we do something about it, I presume. I've seen your 'complement'. The latest patch is not directly affected by that behaviour of parse_url, it is merely a utility method to encode a string as per RFC. It does not try to fix the path and assumes that the only thing that might be wrong with it is the encoding. The issue you've brought up could be fixed separately (with a different bug number, perhaps). We could either parse the url from scratch or have a wrapper function if php version is below 5. That wrapper could then check the validity of the output and return false, just like the php5 function. Parsing the URL from scratch might be a better approach and won't be too hard. I think I'll be able to contribute something. -- Andrei On 22/02/2006, at 3:10 PM, bertrand Gugger wrote: > Case the parse_url() does not answer false. > See my example in complement, the url is not wrong, just assuming > the current scheme and not encoding (what is the target of your > susbsequent method) the "/"in query. > In french, we talk of a fish eating its own tail for that. > > Anuway, the result of parse_url() is nowadays to be checked , you > won't foreach(false as $k => $v) > Then, if checked, it will gently fail as do modern PHPs > > I believe, myself, that just missing the scheme is ok. > Don't reply we should ensure it before : in this case I don't need > parse_url() > Anyway, it's unusable as it is. > > Only gurus could save us.