Q: How to set the "TITLE" of a CGI result
Philip Murphy
I have a CGI program which returns a dynamically generated RTF file
based upon the results of a query - on my PC this RTF file is
automatically loaded into Microsoft Word.
Unfortunately, the document has the title "blahblah.exe", i.e. the name
of my CGI program - how do I return a title, e.g. "Document.rtf" to be
used by Word/whatever?
Thanks in advance,
Philip Murphy
p...@i-com.co.uk
Icom Limited
Dean Pentcheff
Philip Murphy <p...@i-com.co.uk> writes:
> I have a CGI program which returns a dynamically generated RTF file
> Unfortunately, the document has the title "blahblah.exe", i.e. the name
> of my CGI program - how do I return a title, e.g. "Document.rtf" to be
> used by Word/whatever?
The standard way to set a title in a document coming over HTTP is to set
the <title>Whatever You Want</title> field in the <head> section of the
document. So the whole document might look something like the following:
Content-type: text/html
<HTML><HEAD><TITLE>Your Title</TITLE>
</HEAD><BODY>
<h1>whatever</h1>
Text... text...
</BODY></HTML>
-Dean
--
N. Dean Pentcheff <pent...@acm.org> WWW: http://tbone.biol.sc.edu/~dean/
Biological Sciences, Univ. of South Carolina, Columbia SC 29208 (803-777-3936)
PGP ID=768/22A1A015 Keyprint=2D 53 87 53 72 4A F2 83 A0 BF CB C0 D1 0E 76 C0
Get PGP keys and information with the command: "finger de...@tbone.biol.sc.edu"
Per 'Pedro' Olsson
Philip Murphy wrote:
>
> I have a CGI program which returns a dynamically generated RTF file
> automatically loaded into Microsoft Word.
>
> of my CGI program - how do I return a title, e.g. "Document.rtf" to be
> used by Word/whatever?
Try including this line among the header lines your CGI program returns:
Content-Disposition: inline; filename="Document.rtf"
- Pedro
Arjen van Mierlo
In article <325161...@algonet.se> Per 'Pedro' Olsson <pe...@algonet.se> writes:
>From: Per 'Pedro' Olsson <pe...@algonet.se>
>Subject: Re: Q: How to set the "TITLE" of a CGI result
>Date: Tue, 01 Oct 1996 11:22:04 -0700
>Content-Disposition: inline; filename="Document.rtf"
Am interested in the same, but above solution didn't work. Anyone got the
right one?
Ar...@disbv.com
__
__ ____ _ ____ _ _
/__\ ( _ \ ( )( ___)( \( ) ** Arjen van Mierlo
/(__)\ ) / _( )( __) ( \\ ) ** arjenvm@xs4all / ar...@dis.nl
(__)(__)(_)\_)(___)(____)(_)\_) ** http://www.xs4all.nl/~arjenvm
Alan Johnson
Per 'Pedro' Olsson wrote:
>
> Philip Murphy wrote:
> >
> > I have a CGI program which returns a dynamically generated RTF file
> > based upon the results of a query - on my PC this RTF file is
> > automatically loaded into Microsoft Word.
> >
> > Unfortunately, the document has the title "blahblah.exe", i.e. the name
> > of my CGI program - how do I return a title, e.g. "Document.rtf" to be
> > used by Word/whatever?
>
> Try including this line among the header lines your CGI program returns:
>
> Content-Disposition: inline; filename="Document.rtf"
>
Neither this nor the suggestion of using the <TITLE> blah blah </TITLE>
do the trick.
In both cases, the browser prompts with the name of the script as the
file name. Any
clues?
TIA
Alan
--
----------------------------------------------------------------------------
Alan Johnson MIS Director
email: alan.j...@gel.com General Engineering
Labs
v: (803) 556-8171 f: (803) 766-1178 2040 Savage Road, Charleston,SC
29414
Philip Murphy
Arjen van Mierlo wrote:
>
> >Philip Murphy wrote:
> >>
> >> I have a CGI program which returns a dynamically generated RTF file
> >> based upon the results of a query - on my PC this RTF file is
> >> automatically loaded into Microsoft Word.
> >>
> >> Unfortunately, the document has the title "blahblah.exe", i.e. the name
> >> of my CGI program - how do I return a title, e.g. "Document.rtf" to be
> >> used by Word/whatever?
>
> >Try including this line among the header lines your CGI program returns:
>
> >Content-Disposition: inline; filename="Document.rtf"
>
> right one?
This worked fine for me first time!
Phil Murphy (original poster)
p...@i-com.co.uk
Icom Limited
Jocelyn Paine
the browser to "think" that it is using a different URL from the one
it thinks it has. For example, I have a form which the user can submit.
Depending on the user's data, the server will return either a page
containing an error message, or the results of running a program. I
would like the browser to think that the first one has URL "error.htm",
but the second has URL "results.htm".
There's no way to do this with the URL in the <FORM> command, because
that is fixed when you write the command.
Jocelyn Paine
http://users.ox.ac.uk/~popx
fiv...@iiiii.com
In <1996Oct2.165241@oxvaxd> po...@vax.oxford.ac.uk (Jocelyn Paine)
writes:
Simple as 1-2-3
1.) Read in and process user input.
2.) Write the file to server disk, call it "file.rtf" (or "error.htm")
and NOW send the header!
3.) print "Location: file.rtf\n\n"
This is redirection of the browser at the server level and is
completely transparent to the client.
Hope that helps...
5-i's
Arjen van Mierlo
In article <325256...@i-com.co.uk> Philip Murphy <p...@i-com.co.uk> writes:
>From: Philip Murphy <p...@i-com.co.uk>
>Subject: Re: Q: How to set the "TITLE" of a CGI result
>Arjen van Mierlo wrote:
>>
>> >Philip Murphy wrote:
>> >>
>> >> I have a CGI program which returns a dynamically generated RTF file
>> >> based upon the results of a query - on my PC this RTF file is
>> >> automatically loaded into Microsoft Word.
>> >>
>> >> Unfortunately, the document has the title "blahblah.exe", i.e. the name
>> >> of my CGI program - how do I return a title, e.g. "Document.rtf" to be
>> >> used by Word/whatever?
>>
>> >Try including this line among the header lines your CGI program returns:
>>
>> >Content-Disposition: inline; filename="Document.rtf"
>>
>> Am interested in the same, but above solution didn't work. Anyone got the
>> right one?
>This worked fine for me first time!
Where can I see this in action? I've checked the RFC's (1806/1521) but don't
understand what I'm doing wrong.
I've tried (as a test) the following:
#!/bin/sh
echo 'Content-type: text/html'
echo 'Content-Disposition: inline; filename="output.html"\n\n'
echo '<HTML><HEAD><TITLE>Title</TITLE></HEAD>'
echo '<BODY><H1>Header 1</H1>body</BODY></HTML>'
The script is called test.cgi and when I try to run it, I still see
http://www.disbv.com/htbin/test.cgi instead of http://www.disbv.com/output.html
Philip Murphy
fiv...@iiiii.com wrote:
> [ blah ]
> >I'm interested in this too. I'd like to be able to make my server tell
> >the browser to "think" that it is using a different URL from the one
> >it thinks it has. For example, I have a form which the user can
> submit.
> >Depending on the user's data, the server will return either a page
> >containing an error message, or the results of running a program. I
> >would like the browser to think that the first one has URL
> "error.htm",
> >but the second has URL "results.htm".
> >
> >There's no way to do this with the URL in the <FORM> command, because
> >that is fixed when you write the command.
> >
> >Jocelyn Paine
> >http://users.ox.ac.uk/~popx
>
> Simple as 1-2-3
> 1.) Read in and process user input.
> 2.) Write the file to server disk, call it "file.rtf" (or "error.htm")
> and NOW send the header!
> 3.) print "Location: file.rtf\n\n"
>
> This is redirection of the browser at the server level and is
> completely transparent to the client.
> Hope that helps...
> 5-i's
While this would work, it totally contravenes the idea of producing
dynamic pages, and raises all sorts of issues:
- What naming convention do you use
(i.e. multiple simultaneous accesses to the same CGI script require
separate responses)
- How long should these result files remain on the server
- Who/what is responsible for removing them
... the list goes on.
Philip Murphy
Icom Limited
p...@i-com.co.uk
fiv...@iiiii.com
In <32539C...@i-com.co.uk> Philip Murphy <p...@i-com.co.uk> writes:
>
>> ... [myself wrote previously] ...
>> Simple as 1-2-3
>> 1.) Read in and process user input.
>> 2.) Write the file to server disk, call it "file.rtf" (or
"error.htm")
>> and NOW send the header!
>> 3.) print "Location: file.rtf\n\n"
>>
>> This is redirection of the browser at the server level and is
>> completely transparent to the client.
>> Hope that helps...
>> 5-i's
>
>While this would work, it totally contravenes the idea of producing
>dynamic pages,
instead of just being streamed out directly to the browser? Well, if
you stream it out to the browser, there is NO way AFAIK to reset the
"TITLE" to anything other than your CGI program name. So, perhaps it's
just the concept of resetting the "TITLE" you're objecting to here,
Phillip.
> and raises all sorts of issues:
Go ahead.
> - What naming convention do you use
> (i.e. multiple simultaneous accesses to the same CGI script require
>separate responses)
One simply names the file with the appropriate extension. If it's a
GIF, you'd use *.gif. When the browser receives the document, it
examines the extension and, if it is capable of such, launches the
appropriate gif viewer application. If one had created a RTF doc, when
the browser encounters the .rtf extension, then either an associated
helper application would be invoked to handle it or the user should be
prompted whether they wished to save it to their disk. I say "should
be" because some browsers will balk at even downloading some extensions
it does not know.
(Don't understand the relevance of the reference. Perhaps you could
could explain a bit more fully the problem you see that might arise
during multiple simultaneous accesses.)
> - How long should these result files remain on the server
Well, for at least as long as they're needed. :)
Actually, you may unlink the file *at any point after* the client has
begun downloading it. It will not be removed until the read access is
finished. You could just have your program go to sleep for 60 seconds
(taking you well past the "remote host not answering" timeout) after
sending the redirect and then unlink the file.
> - Who/what is responsible for removing them
The webmaster is, just like with cookie crumbs. If you don't clean
your house regularly, it will end up a bit cluttered.
>... the list goes on.
Go ahead, by all means. I'm certain there must be other issues
regarding this that you're not clear on. However, once an
understanding is gained of what is happening with a Location header
redirection, not only will you see the beauty of this, but will realize
that it is, indeed, the ONLY possible solution to the original
question- How to set the "TITLE" of a CGI result.
hope that helps,
5-i's
$Bill Luebkert
Alan Johnson <alan.j...@gel.com> wrote:
>
> Per 'Pedro' Olsson wrote:
> >
> > Philip Murphy wrote:
> > >
> > > I have a CGI program which returns a dynamically generated RTF file
> > > based upon the results of a query - on my PC this RTF file is
> > > automatically loaded into Microsoft Word.
> > >
> > > Unfortunately, the document has the title "blahblah.exe", i.e. the name
> > > of my CGI program - how do I return a title, e.g. "Document.rtf" to be
> > > used by Word/whatever?
> >
> > Try including this line among the header lines your CGI program returns:
> >
> > Content-Disposition: inline; filename="Document.rtf"
> >
>
> Neither this nor the suggestion of using the <TITLE> blah blah </TITLE>
> do the trick.
> In both cases, the browser prompts with the name of the script as the
> file name. Any
> clues?
You could try calling your script using the PATH_INFO method (or
whatever it's called):
"/cgi-bin/upload.cgi/Document.rtf" (notice / instead of ?)
instead of
"/cgi-bin/upload.cgi?file=Document.rtf" or
"/cgi-bin/upload.cgi?Document.rtf" or whatever method you use.
then get the filename from the PATH_INFO vrbl instead of
QUERY_STRING (for GET) or STDIN (for POST).
--
,-/- __ _ _ $Bill Luebkert
(_/ / ) // // DBE Collectibles
/ ) /--< o // // http://www.westworld.com/~dbe/
-/-' /___/_<_</_</_ Email: d...@westworld.com
Thomas D Brattin
[snip]
> Simple as 1-2-3
> 1.) Read in and process user input.
> 2.) Write the file to server disk, call it "file.rtf" (or "error.htm")
> and NOW send the header!
> 3.) print "Location: file.rtf\n\n"
>
> This is redirection of the browser at the server level and is
> completely transparent to the client.
> Hope that helps...
> 5-i's
>
Redirection at the server level? The HTTP headers sent to the browser are
interpreted by the Browser, not the server. It just so happens that a lot
of browsers have implemented the "location:" header. But it is still a
browser command and is not transparent to the browser (client).
fiv...@iiiii.com
In <01bbb193$fca1ed80$e0dedede@tom> "Thomas D Brattin"
server in question. In that case, while parsing the Location header,
the server will know (because there is not a full URL specified) that
the document exists somewhere on the server and will directly return
it.
| | 1.) request /cgi-bin/goto.pl -> | |4.) Parse header,
| CLIENT | / | SERVER | if no URL then
| | <- 5.) new.html sent / | | retreive new.html
2.) Run CGI program
/ /
Only if the Location: / /
header contains a URL, / /
which is determined when | | /
server parses the header | goto.pl | 3.) output,
output from the CGI program, | | " Location: new.html\n\n"
will it be handled differently.
In that case, the server sends a Status: code of 301 (temporarily
moved) or 302 (pernamently moved) and a Location: http://wherever. and,
ONLY then, will the browser handle (if it can) the retrieval of the
specified doc.
In other words, if goto.pl specifies any document on the server itself
it is a server side redirect and there is NO browser that will react
differently because, truly, the browser is not involved in the least.
I believe your error is in thinking that the CGI program is sending
headers directly to the browser. This is not the case. The CGI
program outputs its headers to the server. Before anything is sent to
the browser, the server will first parse this header and then modify
it. The modifications range from changing "\n" to the required "\r\n"
for http transmission, to adding the Status: code and include, among
other things, server side redirects.
hope this helps,
5-i's
Philip Murphy
fiv...@iiiii.com wrote:
>
> In <32539C...@i-com.co.uk> Philip Murphy <p...@i-com.co.uk> writes:
> >
> >> ... [myself wrote previously] ...
> >> 1.) Read in and process user input.
> >> 2.) Write the file to server disk, call it "file.rtf" (or
> "error.htm")
> >> and NOW send the header!
> >> 3.) print "Location: file.rtf\n\n"
> >While this would work, it totally contravenes the idea of producing
> >dynamic pages,
> Do you say that because it actually exists as a saved file for a time
> instead of just being streamed out directly to the browser? Well, if
> you stream it out to the browser, there is NO way AFAIK to reset the
> "TITLE" to anything other than your CGI program name. So, perhaps
I beg to differ - see other postings, specifically re: the
'Content-Disposition: inline; filename="Document.rtf"' method
> > - What naming convention do you use
> > (i.e. multiple simultaneous accesses to the same CGI script require
> >separate responses)
> One simply names the file with the appropriate extension. If it's a
> GIF, you'd use *.gif. When the browser receives the document, it
> examines the extension and, if it is capable of such, launches the
> appropriate gif viewer application. If one had created a RTF doc,
> (blah)
No, no, you've missed the point - I understand perfectly how the
_extension_ works - it's the whole filename I am interested in
> (Don't understand the relevance of the reference. Perhaps you could
> could explain a bit more fully the problem you see that might arise
> during multiple simultaneous accesses.)
>
You really need me to explain the possible consequences of two or more
people accessing a single document which _each_ person thinks has been
generated specifically for them?
> > - How long should these result files remain on the server
> Well, for at least as long as they're needed. :)
> Actually, you may unlink the file *at any point after* the client has
> begun downloading it. It will not be removed until the read access is
> finished. You could just have your program go to sleep for 60 seconds
> (taking you well past the "remote host not answering" timeout) after
> sending the redirect and then unlink the file.
>
a) How do you know when the client has begun downloading it?
b) How do you know 60 seconds is long enough to download it?
> > - Who/what is responsible for removing them
> The webmaster is, just like with cookie crumbs. If you don't clean
> your house regularly, it will end up a bit cluttered.
>
I'm sorry, but the solution you're proposing here is just so
inelegant... Are you seriously suggesting that rather than
a) write a CGI program which creates a dynamic page, which is sent to
the client and finished with,
I should instead
b) write a CGI program which creates a static page, tells the client
where it is, and that sometime in the not too distant future we hope the
webmaster comes back from lunch to clear up the mess...
Phil Murphy
p...@i-com.co.uk
Icom Limited
Peter Haworth
Thomas D Brattin wrote:
> [snip]
> > 3.) print "Location: file.rtf\n\n"
> > This is redirection of the browser at the server level and is
> > completely transparent to the client.
> Redirection at the server level? The HTTP headers sent to the browser are
> interpreted by the Browser, not the server. It just so happens that a lot
> of browsers have implemented the "location:" header. But it is still a
> browser command and is not transparent to the browser (client).
Some servers handle relative URLs internally, sending the result of the
redirection under the original URL.
--
Peter Haworth p...@edison.ioppublishing.com
Linux - Why use Windows, since there is a door?
Peter Haworth
fiv...@iiiii.com wrote:
> In <32539C...@i-com.co.uk> Philip Murphy <p...@i-com.co.uk> writes:
> >> ... [myself wrote previously] ...
> >> Simple as 1-2-3
> >> 1.) Read in and process user input.
> >> 2.) Write the file to server disk, call it "file.rtf" (or
> "error.htm")
> >> and NOW send the header!
> >> 3.) print "Location: file.rtf\n\n"
> >> This is redirection of the browser at the server level and is
> >> completely transparent to the client.
> >> Hope that helps...
> >> 5-i's
> >While this would work, it totally contravenes the idea of producing
> >dynamic pages,
> Do you say that because it actually exists as a saved file for a time
> instead of just being streamed out directly to the browser? Well, if
> you stream it out to the browser, there is NO way AFAIK to reset the
> "TITLE" to anything other than your CGI program name. So, perhaps it's
> just the concept of resetting the "TITLE" you're objecting to here,
> Phillip.
Why not have your CGI prog accessed as
http://server.com/cgi-path/cgi-prog/filename.ext ?
That way the client sees filename.ext as the file.
It has no way of knowing that /cgi-path/cgi-prog
is actually a CGI program. You can also get some
information from /filename.ext as passed in the
PATH_INFO environment variable. This way you're
not storing any extra files which you don't know
how long to keep for, and the user isn't left with
a URL which might suggest URLs to retrieve the
output of other runs of the CGI program, assuming
your server doesn't handle
"Location: relative-URL" internally.
--
Peter Haworth p...@edison.ioppublishing.com
"give a man a fish, he eats for a day. teach a man to surf, and
he'll never go fishing again..." :-)
5-i's
On 4 Oct 1996 03:38:00 GMT, fiv...@iiiii.com wrote:
>In <01bbb193$fca1ed80$e0dedede@tom> "Thomas D Brattin"
><T...@CssWebs.com> writes:
>>... [edited for brevity, please refer to previous posts in this thread] ...
>>>
>>Redirection at the server level? The HTTP headers sent to the browser
>>are interpreted by the Browser, not the server. It just so happens
>>that a lot of browsers have implemented the "location:" header. But
>>it is still a browser command and is not transparent to the browser
>>(client).
>>
>Not so when the document the client is being redircted to is on the
>server in question. In that case, while parsing the Location header,
>the server will know (because there is not a full URL specified) that
>the document exists somewhere on the server and will directly return
>it.
>...
Having been shown one server that is not configured to behave in this fashion, I
see that I was in error in implying that ALL servers will do this as I
described. Thank-you, Todd. Apologies to Tom.
5-i's
On Fri, 04 Oct 1996 09:58:55 +0100, Peter Haworth <p...@edison.ioppublishing.com>
wrote:
>... [edited for brevity, please refer to previous posts in this thread] ...
>
>Why not have your CGI prog accessed as
>http://server.com/cgi-path/cgi-prog/filename.ext ?
Yes indeed, very good. That will work if you wish to distribute a number of
unique documents sharing a common file name. But, in the case of a revisit, the
new file must then be saved to a different directory, or the first file be
either renamed, moved to a different directory or be overwritten. Perhaps that
may not be regarded as a problem by some.
>That way the client sees filename.ext as the file.
>It has no way of knowing that /cgi-path/cgi-prog
>is actually a CGI program. You can also get some
>information from /filename.ext as passed in the
>PATH_INFO environment variable. This way you're
>not storing any extra files which you don't know
>how long to keep for, and the user isn't left with
>a URL which might suggest URLs to retrieve the
>output of other runs of the CGI program,
Good point when privacy or security would be an issue.
> assuming your server doesn't handle "Location: relative-URL" internally.
Which, as I've been shown, may well be the case for some servers.
Also, if the Method POST was used for the request and the redirection was NOT
handled internally, "the user agent must not automatically redirect the request
unless it can be confirmed by the user, since this might change the conditions
under which the request was issued." <rfc1945.9.3>, which may well be considered
a liability by some for my solution.
5-i's
On Fri, 04 Oct 1996 09:52:56 +0100, Philip Murphy <p...@i-com.co.uk> wrote:
.... [edited for brevity, please refer to previous posts in this thread] ...
>> If you stream it out to the browser, there is NO way AFAIK to reset the
>> "TITLE" to anything other than your CGI program name. So, perhaps
>
>I beg to differ - see other postings, specifically re: the
>'Content-Disposition: inline; filename="Document.rtf"' method
If you wish to use an experimental header extension that works for Mozilla,
that's fine by me.
>...
>You really need me to explain the possible consequences of two or more
>people accessing a single document which _each_ person thinks has been
>generated specifically for them?
OK, I see now the objection you have.
Well, when generating unique documents on the fly, I'm inclined to give them
each a unique file name (say) for the purpose of this example, Doc1Z8A9.rtf.
That's just my personal preference and my proposed solution reflects that. If
it was otherwise, I would have to go with Peter Haworth's
<p...@edison.ioppublishing.com> elegant solution- "have your CGI prog accessed as
http://server.com/cgi-path/cgi-prog/filename.ext". Now, that streams out the
document and sets the "TITLE". However, every unique document so generated will
have the same name and that may be considered a liability by some. Maybe not by
the original poster of the question.
>> > - How long should these result files remain on the server
>> Well, for at least as long as they're needed. :)
>> Actually, you may unlink the file *at any point after* the client has
>> begun downloading it. It will not be removed until the read access is
>> finished. You could just have your program go to sleep for 60 seconds
>> (taking you well past the "remote host not answering" timeout) after
>> sending the redirect and then unlink the file.
>>
>
>a) How do you know when the client has begun downloading it?
I don't. I just feel comfortable with the above assumption.
>b) How do you know 60 seconds is long enough to download it?
Same as for a).
You obviously have a different style and would not feel comfortable with this.
For that matter, I would feel uncomfortable with using HTTP/1.0 experimental
extensions and the associated risks.
>...
>I'm sorry, but the solution you're proposing here is just so
>inelegant... Are you seriously suggesting that rather than
>
>a) write a CGI program which creates a dynamic page, which is sent to
>the client and finished with,
Mmmm, you forgot to mention that you are sending it with an experimental header
that will be ignored by many browsers. Now, I wouldn't suggest you don't do it.
In fact, if we were in competition with each other, I'd prefer you did.
>I should instead
>
>b) write a CGI program which creates a static page, tells the client
>where it is, and that sometime in the not too distant future we hope the
>webmaster comes back from lunch to clear up the mess...
I invented crontab just so I wouldn't have to come back from lunch unless I
wanted to. :-)
Seriously, some servers(*) will automatically retrieve and download the document
when they get the Location: header from the CGI program . If one is using such
a server, at least my desired result (which, admittedly, may be overkill) will
be consistently acheived. If not, the Location: header, though it is not
automatically responded to by some user agents, is still within HTTP/1.0 specs.
(*) Having been shown a server that does NOT do this, the assumption I made in
a previous post that all servers behaved this way is incorrect. Thanks, Todd.
Terje A. Bergesen
fiv...@iiiii.com wrote:
[...]
> Simple as 1-2-3
> 1.) Read in and process user input.
> 2.) Write the file to server disk, call it "file.rtf" (or "error.htm")
> and NOW send the header!
> 3.) print "Location: file.rtf\n\n"
This will work, but creates other problems. Let's say the users that
access the page gets dynamic rtf, and consequently each user might get
a different page. What do you do if 200 users hit the page in abou the
same time? Create temporary filenames and lock them? That will work,
but the document titles will not be under your control anymore...
--
____________________________________________________________________
--- Terje : t.ber...@shell.no - I speak only for ME.
---
--- <!--#include virtual="/docs/std/disclaimer.txt" -->
fiv...@iiiii.com
In <325661...@shell.no> "Terje A. Bergesen" <t.ber...@shell.no>
writes:
>fiv...@iiiii.com wrote:
>
>[...]
>> Simple as 1-2-3
>> 1.) Read in and process user input.
>> 2.) Write the file to server disk, call it "file.rtf" (or
"error.htm")
>> and NOW send the header!
>> 3.) print "Location: file.rtf\n\n"
>
>This will work, but creates other problems. Let's say the users that
>access the page gets dynamic rtf, and consequently each user might get
>a different page. What do you do if 200 users hit the page in abou the
>same time? Create temporary filenames and lock them? That will work,
>but the document titles will not be under your control anymore...
>
control! :)
But, yes, my suggestion IS not quite as simple as 1,2,3 and should only
be considered if a unique filename for each document was desirable
(which would be the case for me) or necessary. Otherwise, they should
just go with streaming the document out after receiving a request for
"/cgi-bin/doc_maker.pl/document.rtf", as per Peter Haworth's
<p...@edison.ioppublishing.com> solution.
There are many ways to make a file name unique. *Guaranteeing* the
uniqueness of the file name may not be considered trivial by some, but
it is a technique that ALL of us must master sooner or later when we
realise that, indeed, 200 instances of any of our programs may be
running at the same time.
In this particular case, the section of code that generates each
filename, must be locked to ensure that only one instance of the
program at a time is executing that section. The locking must be done
with an "atomic" (undividable) action after determining that a lock
does not exist and the lock must be removed after leaving that section
of code. One must consider race conditions and deadlock, but I will
let the reader refer to the many Computer Science texts that address
those issues.
An atomic lock must be a single, uninterruptable statement that both
checks for the existance of the lock and creates it if it doesn't
exist. Some programming languages offer such built in. Perl doesn't,
but an effective one exists, thanks to Walt Hobbs. The following is
offered, for those of you who may need such, under the GNU General
Public License and comes from MHonArc, by Earl Hood, eh...@convex.com,
http://www.oac.uci.edu/indiv/ehood/mhonarc.html, and should be viewed
in that context before being implemented by the developer.
====
# ...
# Non critical code...
# ...
if (!&create_lock_file($LOCKFILE, $LOCKTRIES, $LOCKDELAY, $FORCELOCK)){
&error("ERROR: Unable to create $LOCKFILE after $LOCKTRIES tries");
}
## Race condition exists: if process is terminated before termination
## handlers set, lock file will not get removed.
&set_handler();
# ...
# [Code section that must be locked]
# [Keep it as *short* as possible to avoid a bottleneck]
# [Within it use &error instead of die]
# ...
&clean_up;
# ...
# Non critical code
# ...
sub create_lock_file {
local($file, $tries, $sleep, $force) = @_;
local($umask, $ret);
$ret = 0;
eval '$umask = umask(0777)' if UNIX;
while ($tries > 0) {
if (open(LCK_FILE, "> $file")) {
$ISLOCK = 1;
$ret = 1;
last;
}
# [Note: Use select instead of sleep for finer resolution]
sleep($sleep) if $sleep > 0;
$tries--;
}
if ($force) { # Set lock files if force option set
$ISLOCK = 1; $ret = 1;
}
eval 'umask($umask)' if $UNIX;
$ret;
}
## set_handler() sets up the quit() routine to be called when
## a termination signal is sent to [your program].
sub set_handler {
$SIG{'ABRT'} = 'quit';
$SIG{'HUP'} = 'quit';
$SIG{'INT'} = 'quit';
$SIG{'PIPE'} = 'quit';
$SIG{'QUIT'} = 'quit';
$SIG{'TERM'} = 'quit';
}
sub error {
&clean_up();
die @_, "\n";
}
sub clean_up {
if ($ISLOCK) {
unlink ($LOCKFILE);
$ISLOCK = 0;
}
}
====