Is there a TCL equivalent for php's readfile function?

The Situation:

Imagine two servers A and B. Server B just outputs a PDF file that nicely displays information retrieved from any xml string passed to it via a url parameter. Server A's job is to build an xml string, append this xml string onto a url (pointing to the code on Server B) as a parameter, a开发者_开发问答nd then call the url using php's readfile() function...

The Question:

Is there a way to do the same thing (readfile on remote server and output to browser) in TCL?

---

The TCL readfile equivalent is file http://www.tcl.tk/man/tcl8.6/TclCmd/file.htm

However, it appears that the PHP readfile function has an option to read a file from a URL if the fopen wrappers have been enabled http://php.net/manual/en/function.readfile.php

So in this case you need to use a HTTP client. Try this http://www.tcl.tk/man/tcl8.6/TclCmd/http.htm and there is an example of how to use it here http://wiki.tcl.tk/24061

---

If your script is doing output on its stdout channel (or pretending to) then you can use some extra tricks of Tcl's http package so that you keep the data in the OS layer rather than dragging it through your code directly:

package require http 2

set url "http://example.org/getpdf/fromxml"
set data "<example>this might be your xml</example>"

# Generate headers, based on example from PHP readfile() page
puts "Content-Description: File Transfer"
puts "Content-Type: application/pdf"
puts "Content-Disposition: attachment; filename=example.pdf"
puts "Content-Transfer-Encoding: binary"
puts "Expires: 0"
puts "Cache-Control: must-revalidate, post-check=0, pre-check=0"
puts "Pragma: public"
# No content length; data streamed from elsewhere
puts "";    # End of headers!

set tok [http::geturl $url -query $data -type text/xml -channel stdout]
# You ought to check for errors here I suppose...
http::cleanup $tok

This is assuming that the fetch from the remote host is a POST so default handling of the -query option is suitable. Since we're sending a body in our request, it's not a GET (and it's definitely not a PUT…)