Seems that things are getting a bit complicated.
From your original mail, I guess that what you want to do is to fetch
the file from the remote location to your server, and then serve it from
In that case, the simplest thing to do is
a) fopen the local file - if this fails (because it has not yet been
fetched) then do (b)
b) Fetch the file from the remote server using the O option that Daniel
provided for us all (download a remote file to a named location)
c) Repeat (a)
If you don't find what you need in the php manual, then check the
libcurl manuals (or if you are on linux then the man pages which are
really very good). Most of the functionality can be used by the php
wrapper using the curl_setopt constructs, even if they are not
explicitly mentioned in the php manual.
If you are using a halfway decent web server (apache for instance) then
it will handle the threading requests for you, and presumably all
requests will be read only so you don't have an issue with that anyway.
May be more problematic if you are using windows and IIS, but the theory
is the same.
Kevin Carothers wrote:
> On 8/21/06, *Colleen R. Dick* <platypus_at_proaxis.com
> <mailto:platypus_at_proaxis.com>> wrote:
> I want to invoke a script on a remote server purpose is to
> generate a
> pdf file and send it to the browser. I wish to capture the pdf in the
> background and squirrel it away (since the remote site gives you no
> direct option to do that.)
> I searched the mailing list--surely someone else has wanted to do
> One similar question was brushed off by suggesting that the reader
> the docs and examples and use the dead simple one. Another
> asked a similar question and was advised to "set the options" and
> do it.
> I have read all of the examples and I have read
> It lists a s**tload of options but it doesn't tell you what they
> do or
> give examples. There are a bunch of functions that aren't
> I just wanted you to know that *I have done my homework.* I RTFM and
> the FM is just a skoshe sketchy. Also I am using PHP 4.
> This is my best guess so far.
> Hi Colleen,
> My semi-random thoughts follow, but you'll prolly get a lot of info on
> Google groups... I've done what I think you're asking for under
> vastly similar environments (JSP pages and CGI)- You might already
> be doing what I'm about to suggest, I just can't tell (because I
> don't use libCurl - just the cmd line tool).
> A method would be to set up the remote PDF file as a URL and have PHP
> redirect the browser's connection from YOUR server to the remote-
> BEWARE... a lot of web servers don't allow this, so if you don't have
> say about the remote server's policies, you might be setting yourself
> up for failure.
> Given that that is prolly a dangerous proposition, you'll have to (as
> you say) "squirrel' away the PDF to your web server... that's all
> file, but there are issues--- deleting all the "temporary" PDF's (if
> they are temporary) comes to mind.... also comes the issue of multiple
> requests for the same file.
> Also- I think you have to somehow tell the browser that the binary
> file is a PDF with an HTTP hdr:
> "Content Type: Application/*.PDF"
> (you can google the exact header info)
> -And, some browsers/web servers are really picky about the file
> length for Application/* files so you'll prolly have to add a
> "Content Length: 123456"
> HTTP header too....
> And MSIE needs a "CONTENT-DISPOSITION:" header, I recollect.
> -As I said earlier, you may have multi-threading things to worry
> about if your web server is busy 'squirlling' away a PDF and another
> user makes the same request for the same document- In similar
> situations I've had to implement Perl-coded semaphores to keep
> multiple requests from trashing files that were "in-progress" during
> I don't know about PHP but in Perl, I've had to close STDOUT and
> re-open the stream as Binary for the PDF to display correctly- as
> PDF's are pure binary, not ASCII.
> Don't forget SOME user's don't have browser PDF reader plugins.
> Hope this helps
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on 2006-08-22