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

From: Date: Sun, 07 Jan 2001 09:21:44 +0000
Subject: Re: PHP 4.0 Bug #8552 Updated: fopen doesn't open URL
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.dev 
Request: Send a blank email to php-dev+get-43221@lists.php.net to get a copy of this message
On Sun, Jan 07, 2001 at 09:19:36AM +0200, Boian Bonev wrote: > 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. I agree 100%. > 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. This is a bit more than I would like. > 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... I like this, but can changing $http_response_header into an array of arrays will break existing scripts. $http_response_header hasn't been around for so long (it came about the time we stopped with redirects) and we are changing things by adding redirects back in, so maybe. I would definitely prefer your solution if not for compatibility. One ugly solution might be putting all headers together in one array with some well defined delimiter between the headers. > 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... I would prefer to avoid that input array and just have some defaults, including always following redirects. The rest should be done with CURL or something. Thanks, this is the discussion I wanted, I think the goal should be to have something that follows redirects (by default if a choice) being compatible with pre 4.0.3 and 3.x in 4.0.5. Stig

« previous php.dev (#43221) next »