Re: PHP 4.0 Bug #8552 Updated: fopen doesn't open URL

hi, consider that the most common use of url fopen wrappers is to get just the bare content of an url. default behavior shall follow redirects, etc. about the special cases I can think about something very easy to implement and perhaps very powerful to use. my prob is that this will lack library consistency etc. here I just skip the possibility of adding an advanced http lib supporting cookies, get/post/other methods, etc. and leaving url fopen wrappers as the simplest and easiest way to just get url content. in any case redirects must be followed by the wrappers. in general a http request can be handled in two ways - single and multiple (following redirects) before the request two things may be set - http req headers and library options (including the request type - signle/miltiple, if the user needs the result from the query and misc default values for the user agent, prefered content, easy way for post content, cookies and so). indeed only the request type, request method and user_need_return are options and everything else converts to request headers. after the request except the content there are only http response headers, that may be easily returned like array with an array of header for each request in the chain... the http response code is part of the headers and may be extracted by the library just for convenience... let's now try a 'specification by example' ;-) $url_fopen_wrappers['follow_links']=true; $url_fopen_wrappers['want_detailed_info']=false; $url_fopen_wrappers['method']='POST'; $url_fopen_wrappers['content']='the damn post content itself'; $url_fopen_wrappers['headers']=$req_headers; $fh=fopen('http://my.url/?a=b...'.'r'); ... of course this is ugly and a lib for url processing will be the best solution. but why not if we are about staying compatible... b. > On Fri, Jan 05, 2001 at 07:05:25PM +0100, Cynic wrote: > > At 18:30 5.1. 2001, Zak Greant wrote the following: > > > Perhaps it would be good to throw a notice level error when handling > > > redirects - redirects are often put into place when a resource has > > > moved. If PHP handles them perfectly transparently, then the site > > > admin may not know that a resource has moved til the redirect is > > > removed. > > > > In that case, I would like the notice mechanism be done so > > that it's easy to get the server response code... BTW, what > > would happen if server returned 300 (Multiple Choices)? > > The way it is now, a script could check the contents of > $http_response_header and do a redirect on it's own, it would be > easier for the user, and the right thing in most cases, to follow the > redirect I think. I agree that one should be able to see the response > code. It seems reasonable that $http_response_header is the header for > the final location, but we could in theory also put the header of the > first location (possible several with a chain of redirects) in there. > I'm not sure. > > Might be nice if one could specify if one want to follow redirects or not, > but I don't really see a nice way to specify it. One could have some extra > code in the mode string which seems bad, or we could say that the optional > include_path parameter denotes whether to follow redirects since > include_path doesn't make sense for HTTP URLs anyway. If we do this, I > still think we should follow by default which also seems to be the > behavior in PHP3 and up to 4.0.2. > > Stig