Convert \fP to \fR for easier manual page scraping

1 files changed, 89 insertions, 89 deletions

diff --git a/doc/http.n b/doc/http.n
index 9a97dec..f316153 100644
--- a/doc/http.n
+++ b/doc/http.n
@@ -6,7 +6,7 @@
 '\" See the file "license.terms" for information on usage and redistribution
 '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
 '\" 
-'\" RCS: @(#) $Id: http.n,v 1.23 2004/10/27 12:53:22 dkf Exp $
+'\" RCS: @(#) $Id: http.n,v 1.24 2006/11/15 09:23:01 dkf Exp $
 '\" 
 .so man.macros
 .TH "http" n 2.5 http "Tcl Bundled Packages"
@@ -21,9 +21,9 @@ http \- Client-side implementation of the HTTP/1.0 protocol
 .sp
 \fB::http::geturl \fIurl ?options?\fR
 .sp
-\fB::http::formatQuery\fP \fIkey value\fP ?\fIkey value\fP ...?
+\fB::http::formatQuery\fR \fIkey value\fR ?\fIkey value\fR ...?
 .sp
-\fB::http::reset\fP \fItoken\fP ?\fIwhy\fP?
+\fB::http::reset\fR \fItoken\fR ?\fIwhy\fR?
 .sp
 \fB::http::wait \fItoken\fR
 .sp
@@ -65,7 +65,7 @@ The value is also the name of an array in the ::http namespace
 that contains state information about the transaction.  The elements
 of this array are described in the STATE ARRAY section.
 .PP
-If the \fB-command\fP option is specified, then
+If the \fB-command\fR option is specified, then
 the HTTP operation is done in the background.
 \fB::http::geturl\fR returns immediately after generating the
 HTTP request and the callback is invoked
@@ -75,7 +75,7 @@ applications, the caller can use \fB::http::wait\fR after calling
 \fB::http::geturl\fR to start the event loop.
 .SH COMMANDS
 .TP
-\fB::http::config\fP ?\fIoptions\fR?
+\fB::http::config\fR ?\fIoptions\fR?
 The \fB::http::config\fR command is used to set and query the name of the
 proxy server and port, and the User-Agent name used in the HTTP
 requests.  If no options are specified, then the current configuration
@@ -85,20 +85,20 @@ that setting is returned.  Otherwise, the options should be a set of
 flags and values that define the configuration:
 .RS
 .TP
-\fB\-accept\fP \fImimetypes\fP
+\fB\-accept\fR \fImimetypes\fR
 The Accept header of the request.  The default is */*, which means that
 all types of documents are accepted.  Otherwise you can supply a 
 comma-separated list of mime type patterns that you are
 willing to receive.  For example, "image/gif, image/jpeg, text/*".
 .TP
-\fB\-proxyhost\fP \fIhostname\fP
+\fB\-proxyhost\fR \fIhostname\fR
 The name of the proxy host, if any.  If this value is the
 empty string, the URL host is contacted directly.
 .TP
-\fB\-proxyport\fP \fInumber\fP
+\fB\-proxyport\fR \fInumber\fR
 The proxy port number.
 .TP
-\fB\-proxyfilter\fP \fIcommand\fP
+\fB\-proxyfilter\fR \fIcommand\fR
 The command is a callback that is made during
 \fB::http::geturl\fR
 to determine if a proxy is required for a given host.  One argument, a
@@ -109,7 +109,7 @@ an empty list.  The default filter returns the values of the
 \fB\-proxyhost\fR and \fB\-proxyport\fR settings if they are
 non-empty.
 .TP
-\fB\-urlencoding\fP \fIencoding\fP
+\fB\-urlencoding\fR \fIencoding\fR
 The \fIencoding\fR used for creating the x-url-encoded URLs with
 \fB::http::formatQuery\fR.  The default is \fButf-8\fR, as specified by RFC
 2718.  Prior to http 2.5 this was unspecified, and that behavior can be
@@ -118,12 +118,12 @@ returned by specifying the empty string (\fB{}\fR), although
 \fB::http::formatQuery\fR throwing an error processing non-latin-1
 characters.
 .TP
-\fB\-useragent\fP \fIstring\fP
+\fB\-useragent\fR \fIstring\fR
 The value of the User-Agent header in the HTTP request.  The default
 is \fB"Tcl http client package 2.4."\fR
 .RE
 .TP
-\fB::http::geturl\fP \fIurl\fP ?\fIoptions\fP? 
+\fB::http::geturl\fR \fIurl\fR ?\fIoptions\fR? 
 The \fB::http::geturl\fR command is the main procedure in the package.
 The \fB\-query\fR option causes a POST operation and
 the \fB\-validate\fR option causes a HEAD operation;
@@ -136,25 +136,25 @@ that is invoked when the HTTP transaction completes.
 \fB::http::geturl\fR takes several options:
 .RS
 .TP
-\fB\-binary\fP \fIboolean\fP
+\fB\-binary\fR \fIboolean\fR
 Specifies whether to force interpreting the URL data as binary.  Normally
 this is auto-detected (anything not beginning with a \fBtext\fR content
 type or whose content encoding is \fBgzip\fR or \fBcompress\fR is
 considered binary data).
 .TP
-\fB\-blocksize\fP \fIsize\fP
+\fB\-blocksize\fR \fIsize\fR
 The block size used when reading the URL.
 At most \fIsize\fR bytes are read at once.  After each block, a call to the
 \fB\-progress\fR callback is made (if that option is specified).
 .TP
-\fB\-channel\fP \fIname\fP
+\fB\-channel\fR \fIname\fR
 Copy the URL contents to channel \fIname\fR instead of saving it in
 \fBstate(body)\fR.
 .TP
-\fB\-command\fP \fIcallback\fP
-Invoke \fIcallback\fP after the HTTP transaction completes.
-This option causes \fB::http::geturl\fP to return immediately.
-The \fIcallback\fP gets an additional argument that is the \fItoken\fR returned
+\fB\-command\fR \fIcallback\fR
+Invoke \fIcallback\fR after the HTTP transaction completes.
+This option causes \fB::http::geturl\fR to return immediately.
+The \fIcallback\fR gets an additional argument that is the \fItoken\fR returned
 from \fB::http::geturl\fR. This token is the name of an array that is
 described in the STATE ARRAY section.  Here is a template for the
 callback:
@@ -167,8 +167,8 @@ proc httpCallback {token} {
 .CE
 .RE
 .TP
-\fB\-handler\fP \fIcallback\fP
-Invoke \fIcallback\fP whenever HTTP data is available; if present, nothing
+\fB\-handler\fR \fIcallback\fR
+Invoke \fIcallback\fR whenever HTTP data is available; if present, nothing
 else will be done with the HTTP data.  This procedure gets two additional
 arguments: the socket for the HTTP data and the \fItoken\fR returned from
 \fB::http::geturl\fR.  The token is the name of a global array that is described
@@ -187,7 +187,7 @@ proc httpHandlerCallback {socket token} {
 .CE
 .RE
 .TP
-\fB\-headers\fP \fIkeyvaluelist\fP
+\fB\-headers\fR \fIkeyvaluelist\fR
 This option is used to add extra headers to the HTTP request.  The
 \fIkeyvaluelist\fR argument must be a list with an even number of
 elements that alternate between keys and values.  The keys become
@@ -199,7 +199,7 @@ HTTP request:
 Pragma: no-cache
 .CE
 .TP
-\fB\-progress\fP \fIcallback\fP
+\fB\-progress\fR \fIcallback\fR
 The \fIcallback\fR is made after each transfer of data from the URL.
 The callback gets three additional arguments: the \fItoken\fR from
 \fB::http::geturl\fR, the expected total size of the contents from the
@@ -215,13 +215,13 @@ proc httpProgress {token total current} {
 .CE
 .RE
 .TP
-\fB\-query\fP \fIquery\fP
+\fB\-query\fR \fIquery\fR
 This flag causes \fB::http::geturl\fR to do a POST request that passes the
 \fIquery\fR to the server. The \fIquery\fR must be an x-url-encoding
 formatted query.  The \fB::http::formatQuery\fR procedure can be used to
 do the formatting.
 .TP
-\fB\-queryblocksize\fP \fIsize\fP
+\fB\-queryblocksize\fR \fIsize\fR
 The block size used when posting query data to the URL.
 At most 
 \fIsize\fR
@@ -229,35 +229,35 @@ bytes are written at once.  After each block, a call to the
 \fB\-queryprogress\fR
 callback is made (if that option is specified).
 .TP
-\fB\-querychannel\fP \fIchannelID\fP
+\fB\-querychannel\fR \fIchannelID\fR
 This flag causes \fB::http::geturl\fR to do a POST request that passes the
 data contained in \fIchannelID\fR to the server. The data contained in
 \fIchannelID\fR must be an x-url-encoding
-formatted query unless the \fB\-type\fP option below is used.
+formatted query unless the \fB\-type\fR option below is used.
 If a Content-Length header is not specified via the \fB\-headers\fR options,
 \fB::http::geturl\fR attempts to determine the size of the post data
 in order to create that header.  If it is
 unable to determine the size, it returns an error.
 .TP
-\fB\-queryprogress\fP \fIcallback\fP
+\fB\-queryprogress\fR \fIcallback\fR
 The \fIcallback\fR is made after each transfer of data to the URL
 (i.e. POST) and acts exactly like the \fB\-progress\fR option (the
 callback format is the same).
 .TP
-\fB\-timeout\fP \fImilliseconds\fP
+\fB\-timeout\fR \fImilliseconds\fR
 If \fImilliseconds\fR is non-zero, then \fB::http::geturl\fR sets up a timeout
 to occur after the specified number of milliseconds.
-A timeout results in a call to \fB::http::reset\fP and to
-the \fB-command\fP callback, if specified.
-The return value of \fB::http::status\fP is \fBtimeout\fP
+A timeout results in a call to \fB::http::reset\fR and to
+the \fB-command\fR callback, if specified.
+The return value of \fB::http::status\fR is \fBtimeout\fR
 after a timeout has occurred.
 .TP
-\fB\-type\fP \fImime-type\fP
+\fB\-type\fR \fImime-type\fR
 Use \fImime-type\fR as the \fBContent-Type\fR value, instead of the
 default value (\fBapplication/x-www-form-urlencoded\fR) during a
 POST operation.
 .TP
-\fB\-validate\fP \fIboolean\fP
+\fB\-validate\fR \fIboolean\fR
 If \fIboolean\fR is non-zero, then \fB::http::geturl\fR does an HTTP HEAD
 request.  This request returns meta information about the URL, but the
 contents are not returned.  The meta information is available in the
@@ -265,62 +265,62 @@ contents are not returned.  The meta information is available in the
 ARRAY section for details.
 .RE
 .TP
-\fB::http::formatQuery\fP \fIkey value\fP ?\fIkey value\fP ...?
+\fB::http::formatQuery\fR \fIkey value\fR ?\fIkey value\fR ...?
 This procedure does x-url-encoding of query data.  It takes an even
 number of arguments that are the keys and values of the query.  It
 encodes the keys and values, and generates one string that has the
 proper & and = separators.  The result is suitable for the
 \fB\-query\fR value passed to \fB::http::geturl\fR.
 .TP
-\fB::http::reset\fP \fItoken\fP ?\fIwhy\fP?
+\fB::http::reset\fR \fItoken\fR ?\fIwhy\fR?
 This command resets the HTTP transaction identified by \fItoken\fR, if
-any.  This sets the \fBstate(status)\fP value to \fIwhy\fP, which defaults to \fBreset\fR, and then calls the registered \fB\-command\fR callback.
+any.  This sets the \fBstate(status)\fR value to \fIwhy\fR, which defaults to \fBreset\fR, and then calls the registered \fB\-command\fR callback.
 .TP
-\fB::http::wait\fP \fItoken\fP
+\fB::http::wait\fR \fItoken\fR
 This is a convenience procedure that blocks and waits for the
 transaction to complete.  This only works in trusted code because it
 uses \fBvwait\fR.  Also, it's not useful for the case where
-\fB::http::geturl\fP is called \fIwithout\fP the \fB-command\fP option
-because in this case the \fB::http::geturl\fP call doesn't return
+\fB::http::geturl\fR is called \fIwithout\fR the \fB-command\fR option
+because in this case the \fB::http::geturl\fR call doesn't return
 until the HTTP transaction is complete, and thus there's nothing to
 wait for.
 .TP
-\fB::http::data\fP \fItoken\fP
-This is a convenience procedure that returns the \fBbody\fP element
+\fB::http::data\fR \fItoken\fR
+This is a convenience procedure that returns the \fBbody\fR element
 (i.e., the URL data) of the state array.
 .TP
-\fB::http::error\fP \fItoken\fP
-This is a convenience procedure that returns the \fBerror\fP element
+\fB::http::error\fR \fItoken\fR
+This is a convenience procedure that returns the \fBerror\fR element
 of the state array.
 .TP
-\fB::http::status\fP \fItoken\fP
-This is a convenience procedure that returns the \fBstatus\fP element of
+\fB::http::status\fR \fItoken\fR
+This is a convenience procedure that returns the \fBstatus\fR element of
 the state array.
 .TP
-\fB::http::code\fP \fItoken\fP
-This is a convenience procedure that returns the \fBhttp\fP element of the
+\fB::http::code\fR \fItoken\fR
+This is a convenience procedure that returns the \fBhttp\fR element of the
 state array.
 .TP
-\fB::http::ncode\fP \fItoken\fP
+\fB::http::ncode\fR \fItoken\fR
 This is a convenience procedure that returns just the numeric return
-code (200, 404, etc.) from the \fBhttp\fP element of the state array.
+code (200, 404, etc.) from the \fBhttp\fR element of the state array.
 .TP
-\fB::http::size\fP \fItoken\fP
-This is a convenience procedure that returns the \fBcurrentsize\fP
+\fB::http::size\fR \fItoken\fR
+This is a convenience procedure that returns the \fBcurrentsize\fR
 element of the state array, which represents the number of bytes
-received from the URL in the \fB::http::geturl\fP call.
+received from the URL in the \fB::http::geturl\fR call.
 .TP
-\fB::http::cleanup\fP \fItoken\fP
+\fB::http::cleanup\fR \fItoken\fR
 This procedure cleans up the state associated with the connection
-identified by \fItoken\fP.  After this call, the procedures
-like \fB::http::data\fP cannot be used to get information
-about the operation.  It is \fIstrongly\fP recommended that you call
+identified by \fItoken\fR.  After this call, the procedures
+like \fB::http::data\fR cannot be used to get information
+about the operation.  It is \fIstrongly\fR recommended that you call
 this function after you're done with a given HTTP request.  Not doing
 so will result in memory not being freed, and if your app calls
-\fB::http::geturl\fP enough times, the memory leak could cause a
+\fB::http::geturl\fR enough times, the memory leak could cause a
 performance hit...or worse.
 .TP
-\fB::http::register\fP \fIproto port command\fP
+\fB::http::register\fR \fIproto port command\fR
 This procedure allows one to provide custom HTTP transport types
 such as HTTPS, by registering a prefix, the default port, and the
 command to execute to create the Tcl \fBchannel\fR. E.g.:
@@ -335,12 +335,12 @@ set token [::http::geturl https://my.secure.site/]
 .CE
 .RE
 .TP
-\fB::http::unregister\fP \fIproto\fP
+\fB::http::unregister\fR \fIproto\fR
 This procedure unregisters a protocol handler that was previously
 registered via \fB::http::register\fR.
 
 .SH "ERRORS"
-The \fB::http::geturl\fP procedure will raise errors in the following cases:
+The \fB::http::geturl\fR procedure will raise errors in the following cases:
 invalid command line options,
 an invalid URL,
 a URL on a non-existent host,
@@ -349,59 +349,59 @@ These errors mean that it
 cannot even start the network transaction.
 It will also raise an error if it gets an I/O error while
 writing out the HTTP request header.
-For synchronous \fB::http::geturl\fP calls (where \fB-command\fP is
+For synchronous \fB::http::geturl\fR calls (where \fB-command\fR is
 not specified), it will raise an error if it gets an I/O error while
-reading the HTTP reply headers or data.  Because \fB::http::geturl\fP
+reading the HTTP reply headers or data.  Because \fB::http::geturl\fR
 doesn't return a token in these cases, it does all the required
 cleanup and there's no issue of your app having to call
-\fB::http::cleanup\fP.
+\fB::http::cleanup\fR.
 .PP
-For asynchronous \fB::http::geturl\fP calls, all of the above error
+For asynchronous \fB::http::geturl\fR calls, all of the above error
 situations apply, except that if there's any error while 
 reading the
 HTTP reply headers or data, no exception is thrown.  This is because
-after writing the HTTP headers, \fB::http::geturl\fP returns, and the
+after writing the HTTP headers, \fB::http::geturl\fR returns, and the
 rest of the HTTP transaction occurs in the background.  The command
 callback can check if any error occurred during the read by calling
-\fB::http::status\fP to check the status and if its \fIerror\fP,
-calling \fB::http::error\fP to get the error message.
+\fB::http::status\fR to check the status and if its \fIerror\fR,
+calling \fB::http::error\fR to get the error message.
 .PP
 Alternatively, if the main program flow reaches a point where it needs
 to know the result of the asynchronous HTTP request, it can call
-\fB::http::wait\fP and then check status and error, just as the
+\fB::http::wait\fR and then check status and error, just as the
 callback does.
 .PP
 In any case, you must still call
-\fB::http::cleanup\fP to delete the state array when you're done.
+\fB::http::cleanup\fR to delete the state array when you're done.
 .PP
 There are other possible results of the HTTP transaction
-determined by examining the status from \fB::http::status\fP.
+determined by examining the status from \fB::http::status\fR.
 These are described below.
 .TP
 ok
-If the HTTP transaction completes entirely, then status will be \fBok\fP.
-However, you should still check the \fB::http::code\fP value to get
-the HTTP status.  The \fB::http::ncode\fP procedure provides just
-the numeric error (e.g., 200, 404 or 500) while the \fB::http::code\fP
+If the HTTP transaction completes entirely, then status will be \fBok\fR.
+However, you should still check the \fB::http::code\fR value to get
+the HTTP status.  The \fB::http::ncode\fR procedure provides just
+the numeric error (e.g., 200, 404 or 500) while the \fB::http::code\fR
 procedure returns a value like "HTTP 404 File not found".
 .TP
 eof
 If the server closes the socket without replying, then no error
-is raised, but the status of the transaction will be \fBeof\fP.
+is raised, but the status of the transaction will be \fBeof\fR.
 .TP
 error
-The error message will also be stored in the \fBerror\fP status
-array element, accessible via \fB::http::error\fP.
+The error message will also be stored in the \fBerror\fR status
+array element, accessible via \fB::http::error\fR.
 .PP
-Another error possibility is that \fB::http::geturl\fP is unable to
+Another error possibility is that \fB::http::geturl\fR is unable to
 write all the post query data to the server before the server
 responds and closes the socket.
-The error message is saved in the \fBposterror\fP status array
-element and then  \fB::http::geturl\fP attempts to complete the
+The error message is saved in the \fBposterror\fR status array
+element and then  \fB::http::geturl\fR attempts to complete the
 transaction.
 If it can read the server's response
-it will end up with an \fBok\fP status, otherwise it will have
-an \fBeof\fP status.
+it will end up with an \fBok\fR status, otherwise it will have
+an \fBeof\fR status.
 
 .SH "STATE ARRAY"
 The \fB::http::geturl\fR procedure returns a \fItoken\fR that can be used to
@@ -412,14 +412,14 @@ upvar #0 $token state
 .CE
 Once the data associated with the URL is no longer needed, the state
 array should be unset to free up storage.
-The \fB::http::cleanup\fP procedure is provided for that purpose.
+The \fB::http::cleanup\fR procedure is provided for that purpose.
 The following elements of
 the array are supported:
 .RS
 .TP
 \fBbody\fR
 The contents of the URL.  This will be empty if the \fB\-channel\fR
-option has been specified.  This value is returned by the \fB::http::data\fP command.
+option has been specified.  This value is returned by the \fB::http::data\fR command.
 .TP
 \fBcharset\fR
 The value of the charset attribute from the \fBContent-Type\fR meta-data
@@ -432,7 +432,7 @@ A copy of the \fBContent-Encoding\fR meta-data value.
 .TP
 \fBcurrentsize\fR
 The current number of bytes fetched from the URL.
-This value is returned by the \fB::http::size\fP command.
+This value is returned by the \fB::http::size\fR command.
 .TP
 \fBerror\fR
 If defined, this is the error string seen when the HTTP transaction
@@ -440,10 +440,10 @@ was aborted.
 .TP
 \fBhttp\fR
 The HTTP status reply from the server.  This value
-is returned by the \fB::http::code\fP command.  The format of this value is:
+is returned by the \fB::http::code\fR command.  The format of this value is:
 .RS
 .CS
-\fIHTTP/1.0 code string\fP
+\fIHTTP/1.0 code string\fR
 .CE
 The \fIcode\fR is a three-digit number defined in the HTTP standard.
 A code of 200 is OK.  Codes beginning with 4 or 5 indicate errors.
@@ -483,7 +483,7 @@ the post query data to the server.
 .TP
 \fBstatus\fR
 Either \fBok\fR, for successful completion, \fBreset\fR for
-user-reset, \fBtimeout\fP if a timeout occurred before the transaction
+user-reset, \fBtimeout\fR if a timeout occurred before the transaction
 could complete, or \fBerror\fR for an error condition.  During the
 transaction this value is the empty string.
 .TP