[MANUAL] English:

- unified "HTTP" and "HTTPS" with acronym

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@21826 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/en/module_specs/Zend_Controller-Request.xml

@@ -192,7 +192,7 @@
                     <varname>$_SERVER['REQUEST_URI']</varname>. If you are using such
                     a setup and getting invalid routing, you should use the
                     <classname>Zend_Controller_Request_Apache404</classname> class instead
-                    of the default Http class for your request object:
+                    of the default <acronym>HTTP</acronym> class for your request object:
                 </para>
 
                 <programlisting language="php"><![CDATA[

documentation/manual/en/module_specs/Zend_Feed_Pubsubhubbub.xml

@@ -23,13 +23,13 @@
 
         <para>
             Pubsubhubbub has garnered attention because it is a pubsub protocol which is easy to
-            implement and which operates over HTTP. Its philosophy is to replace the traditional
-            model where blog feeds have been polled at regular intervals to detect and retrieve
-            updates. Depending on the frequency of polling, this can take a lot of time to
-            propagate updates to interested parties from planet aggregators to desktop readers. With
-            a pubsub system in place, updates are not simply polled by Subscribers, they are pushed
-            to Subscribers, elimenating any delay. For this reason, Pubsubhubbub forms part of what
-            has been dubbed the real-time web.
+            implement and which operates over <acronym>HTTP</acronym>. Its philosophy is to replace
+            the traditional model where blog feeds have been polled at regular intervals to detect
+            and retrieve updates. Depending on the frequency of polling, this can take a lot of time
+            to propagate updates to interested parties from planet aggregators to desktop readers.
+            With a pubsub system in place, updates are not simply polled by Subscribers, they are
+            pushed to Subscribers, elimenating any delay. For this reason, Pubsubhubbub forms part
+            of what has been dubbed the real-time web.
         </para>
 
         <para>
@@ -101,10 +101,10 @@
             updates it with new content. This may be a blog, an aggregator, or even a web service
             with a public feed based <acronym>API</acronym>. In order for these updates to be pushed
             to Subscribers, the Publisher must notify all of its supported Hubs that an update has
-            occured using a simple HTTP POST request containing the URI or the updated Topic (i.e
-            the updated RSS or Atom feed). The Hub will confirm receipt of the notification, fetch
-            the updated feed, and forward any updates to any Subscribers who have subscribed to that
-            Hub for updates from the relevant feed.
+            occured using a simple <acronym>HTTP</acronym> POST request containing the URI or the
+            updated Topic (i.e the updated RSS or Atom feed). The Hub will confirm receipt of the
+            notification, fetch the updated feed, and forward any updates to any Subscribers who
+            have subscribed to that Hub for updates from the relevant feed.
         </para>
 
         <para>
@@ -125,10 +125,10 @@
             a pair of local RSS and Atom feeds. The class retains a collection of errors which
             include the Hub URLs, so the notification can be re-attempted later and/or logged if any
             notifications happen to fail. Each resulting error array also includes a "response" key
-            containing the related HTTP response object. In the event of any errors, it is strongly
-            recommended to attempt the operation for failed Hub Endpoints at least once more at a
-            future time. This may require the use of either a scheduled task for this purpose or
-            a job queue though such extra steps are optional.
+            containing the related <acronym>HTTP</acronym> response object. In the event of any
+            errors, it is strongly recommended to attempt the operation for failed Hub Endpoints at
+            least once more at a future time. This may require the use of either a scheduled task
+            for this purpose or a job queue though such extra steps are optional.
         </para>
 
         <programlisting language="php"><![CDATA[

documentation/manual/en/module_specs/Zend_Gdata_AuthSub.xml

@@ -69,14 +69,14 @@
             <methodname>Zend_Gdata_AuthSub::getHttpClient()</methodname>.
             This function returns an instance of <classname>Zend_Http_Client</classname>,
             with appropriate headers set so that subsequent requests your
-            application submits using that Http Client are also authenticated.
+            application submits using that <acronym>HTTP</acronym> Client are also authenticated.
         </para>
 
         <para>
             Below is an example of <acronym>PHP</acronym> code for a web application
             to acquire authentication to use the Google Calendar service
             and create a <classname>Zend_Gdata</classname> client object using that authenticated
-            Http Client.
+            <acronym>HTTP</acronym> Client.
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -140,7 +140,7 @@ if (isset($_GET['logout'])) {
                 The treatment of the <varname>$php_self</varname> variable in the
                 example above is a general security guideline, it is not
                 specific to <classname>Zend_Gdata</classname>. You should always filter content you
-                output to http headers.
+                output to <acronym>HTTP</acronym> headers.
             </para>
 
             <para>

documentation/manual/en/module_specs/Zend_Gdata_ClientLogin.xml

@@ -6,7 +6,7 @@
     <para>
         The ClientLogin mechanism enables you to write <acronym>PHP</acronym> application
         that acquire authenticated access to Google Services,
-        specifying a user's credentials in the Http Client.
+        specifying a user's credentials in the <acronym>HTTP</acronym> Client.
     </para>
 
     <para>
@@ -35,7 +35,7 @@
         <title>Creating a ClientLogin authenticated Http Client</title>
 
         <para>
-            The process of creating an authenticated Http client using
+            The process of creating an authenticated <acronym>HTTP</acronym> client using
             the ClientLogin mechanism is to call the static function
             <methodname>Zend_Gdata_ClientLogin::getHttpClient()</methodname>
             and pass the Google account credentials in plain text.

documentation/manual/en/module_specs/Zend_Http_Client-Advanced.xml

@@ -13,8 +13,8 @@
         </para>
 
         <para>
-            According to the HTTP/1.1 RFC, HTTP 301 and 302 responses should be
-            treated by the client by resending the same request to the
+            According to the <acronym>HTTP</acronym>/1.1 RFC, <acronym>HTTP</acronym> 301 and 302
+            responses should be treated by the client by resending the same request to the
             specified location - using the same request method. However, most
             clients to not implement this and always use a GET request when
             redirecting. By default, <classname>Zend_Http_Client</classname> does the same - when
@@ -163,7 +163,7 @@ $client->setHeaders(array(
         <title>File Uploads</title>
 
         <para>
-            You can upload files through HTTP using the setFileUpload method.
+            You can upload files through <acronym>HTTP</acronym> using the setFileUpload method.
             This method takes a file name as the first parameter, a form name
             as the second parameter, and data as a third optional parameter.
             If the third data parameter is <constant>NULL</constant>, the first file name parameter
@@ -263,10 +263,10 @@ $client->setRawData($xml)->setEncType('text/xml')->request('POST');
         <title>HTTP Authentication</title>
 
         <para>
-            Currently, <classname>Zend_Http_Client</classname> only supports basic HTTP
-            authentication. This feature is utilized using the <methodname>setAuth()</methodname>
-            method, or by specifying a username and a password in the URI. The
-            <methodname>setAuth()</methodname> method
+            Currently, <classname>Zend_Http_Client</classname> only supports basic
+            <acronym>HTTP</acronym> authentication. This feature is utilized using the
+            <methodname>setAuth()</methodname> method, or by specifying a username and a password in
+            the URI. The <methodname>setAuth()</methodname> method
             takes 3 parameters: The user name, the password and an optional
             authentication type parameter. As mentioned, currently only basic
             authentication is supported (digest authentication support is
@@ -417,7 +417,7 @@ $client->setRawData($fp, 'application/zip')->request('PUT');
         </para>
 
         <para>
-            Only PUT requests currently support sending streams to HTTP server.
+            Only PUT requests currently support sending streams to <acronym>HTTP</acronym> server.
         </para>
 
         <para>

documentation/manual/en/module_specs/Zend_Http_Client.xml

@@ -193,7 +193,7 @@ $client->setConfig($config);
         <title>Performing Basic HTTP Requests</title>
 
         <para>
-            Performing simple HTTP requests is very easily done using the
+            Performing simple <acronym>HTTP</acronym> requests is very easily done using the
             request() method, and rarely needs more than three lines of code:
 
             <example id="zend.http.client.basic-requests.example-1">
@@ -207,7 +207,7 @@ $response = $client->request();
 
             The request() method takes one optional parameter - the request method.
             This can be either GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS or
-            CONNECT as defined by the HTTP protocol
+            CONNECT as defined by the <acronym>HTTP</acronym> protocol
 
             <footnote>
               <para>
@@ -243,7 +243,7 @@ $response = $client->request();
         <title>Adding GET and POST parameters </title>
 
         <para>
-            Adding GET parameters to an HTTP request is quite simple, and can
+            Adding GET parameters to an <acronym>HTTP</acronym> request is quite simple, and can
             be done either by specifying them as part of the URL, or by using
             the setParameterGet() method.
             This method takes the GET parameter's name as its first parameter,

documentation/manual/en/module_specs/Zend_Http_Cookie-Handling.xml

@@ -172,8 +172,8 @@ $cookie = Zend_Http_Cookie::fromString('foo=bar; secure;',
 
         <para>
             A cookie object can be transferred back into a string, using the __toString() magic
-            method. This method will produce a HTTP request "Cookie" header string, showing the
-            cookie's name and value, and terminated by a semicolon (';').
+            method. This method will produce a <acronym>HTTP</acronym> request "Cookie" header
+            string, showing the cookie's name and value, and terminated by a semicolon (';').
             The value will be URL encoded, as expected in a Cookie header:
             <example id="zend.http.cookies.cookie.instantiating.example-2">
                <title>Stringifying a Zend_Http_Cookie object</title>

documentation/manual/en/module_specs/Zend_Http_Response.xml

@@ -16,8 +16,9 @@
 
         <para>
             In most cases, a <classname>Zend_Http_Response</classname> object will be instantiated
-            using the fromString() method, which reads a string containing an HTTP
-            response message, and returns a new <classname>Zend_Http_Response</classname> object:
+            using the fromString() method, which reads a string containing a
+            <acronym>HTTP</acronym> response message, and returns a new
+            <classname>Zend_Http_Response</classname> object:
             <example id="zend.http.response.introduction.example-1">
                 <title>Instantiating a Zend_Http_Response Object Using the Factory Method</title>
 

documentation/manual/en/module_specs/Zend_Oauth-GettingStarted.xml

@@ -176,8 +176,9 @@ if (!empty($_GET) && isset($_SESSION['TWITTER_REQUEST_TOKEN'])) {
         Success! We have an authorized access token - so it's time to actually
         use the Twitter <acronym>API</acronym>. Since the access token must be included with every
         single <acronym>API</acronym> request, <classname>Zend_Oauth_Consumer</classname> offers a
-        ready-to-go HTTP client (a subclass of <classname>Zend_Http_Client</classname>) to use
-        either by itself or by passing it as a custom HTTP Client to another library or
+        ready-to-go <acronym>HTTP</acronym> client (a subclass of
+        <classname>Zend_Http_Client</classname>) to use either by itself or by passing it as a
+        custom <acronym>HTTP</acronym> Client to another library or
         component. Here's an example of using it standalone. This can be done
         from anywhere in your application, so long as you can access the OAuth
         configuration and retrieve the final authorized access token.

documentation/manual/en/module_specs/Zend_Oauth-ProtocolWorkflow.xml

@@ -28,12 +28,13 @@
 
     <para>
         In the meantime TweetExpress has been busy. Before gaining your approval from Twitter, it
-        has sent a HTTP request to Twitter's service asking for a new unauthorized Request Token.
-        This token is not User specific from Twitter's perspective, but TweetExpress may use it
-        specifically for the current User and should associate it with their account and store it
-        for future use. TweetExpress now redirects the User to Twitter so they can approve
-        TweetExpress' access. The URL for this redirect will be signed using TweetExpress' Consumer
-        Secret and it will contain the unauthorized Request Token as a parameter.
+        has sent a <acronym>HTTP</acronym> request to Twitter's service asking for a new
+        unauthorized Request Token. This token is not User specific from Twitter's perspective, but
+        TweetExpress may use it specifically for the current User and should associate it with their
+        account and store it for future use. TweetExpress now redirects the User to Twitter so they
+        can approve TweetExpress' access. The URL for this redirect will be signed using
+        TweetExpress' Consumer Secret and it will contain the unauthorized Request Token as a
+        parameter.
     </para>
 
     <para>

documentation/manual/en/module_specs/Zend_Oauth-SecurityArchitecture.xml

@@ -4,24 +4,25 @@
     <title>Security Architecture</title>
 
     <para>
-        OAuth was designed specifically to operate over an insecure HTTP connection and so the use
-        of HTTPS is not required though obviously it would be desireable if available. Should a
-        HTTPS connection be feasible, OAuth offers a signature method implementation called
-        PLAINTEXT which may be utilised. Over a typical unsecured HTTP connection, the use of
-        PLAINTEXT must be avoided and an alternate scheme using. The OAuth specification defines two
-        such signature methods: HMAC-SHA1 and RSA-SHA1. Both are fully supported by
-        <classname>Zend_Oauth</classname>.
+        OAuth was designed specifically to operate over an insecure <acronym>HTTP</acronym>
+        connection and so the use of <acronym>HTTPS</acronym> is not required though obviously it
+        would be desireable if available. Should a <acronym>HTTPS</acronym> connection be feasible,
+        OAuth offers a signature method implementation called PLAINTEXT which may be utilised. Over
+        a typical unsecured <acronym>HTTP</acronym> connection, the use of PLAINTEXT must be avoided
+        and an alternate scheme using. The OAuth specification defines two such signature methods:
+        HMAC-SHA1 and RSA-SHA1. Both are fully supported by <classname>Zend_Oauth</classname>.
     </para>
 
     <para>
         These signature methods are quite easy to understand. As you can imagine, a PLAINTEXT
-        signature method does nothing that bears mentioning since it relies on HTTPS. If you were to
-        use PLAINTEXT over HTTP, you are left with a significant problem: there's no way to be sure
-        that the content of any OAuth enabled request (which would include the OAuth Access Token)
-        was altered en route. This is because unsecured HTTP requests are always at risk of
-        eavesdropping, Man In The Middle (MITM) attacks, or other risks whereby a request can be
-        retooled so to speak to perform tasks on behalf of the attacker by masquerading as the
-        origin application without being noticed by the service provider.
+        signature method does nothing that bears mentioning since it relies on
+        <acronym>HTTPS</acronym>. If you were to use PLAINTEXT over <acronym>HTTP</acronym>, you are
+        left with a significant problem: there's no way to be sure that the content of any OAuth
+        enabled request (which would include the OAuth Access Token) was altered en route. This is
+        because unsecured <acronym>HTTP</acronym> requests are always at risk of eavesdropping, Man
+        In The Middle (MITM) attacks, or other risks whereby a request can be retooled so to speak
+        to perform tasks on behalf of the attacker by masquerading as the origin application without
+        being noticed by the service provider.
     </para>
 
     <para>
@@ -71,9 +72,10 @@
 
     <para>
         As a final point, this is not an exhaustive look at the security architecture in OAuth. For
-        example, what if HTTP requests which contain both the Access Token and the Consumer Secret
-        are eavesdropped? The system relies on at one in the clear transmission of each unless HTTPS
-        is active, so the obvious conclusion is that where feasible HTTPS is to be preferred leaving
-        unsecured HTTP in place only where it is not possible or affordable to do so.
+        example, what if <acronym>HTTP</acronym> requests which contain both the Access Token and
+        the Consumer Secret are eavesdropped? The system relies on at one in the clear transmission
+        of each unless <acronym>HTTPS</acronym> is active, so the obvious conclusion is that where
+        feasible <acronym>HTTPS</acronym> is to be preferred leaving unsecured
+        <acronym>HTTP</acronym> in place only where it is not possible or affordable to do so.
     </para>
 </sect2>

documentation/manual/en/module_specs/Zend_View-Helpers-Currency.xml

@@ -45,9 +45,9 @@
     <para>
         There are several ways to select the desired currency. First, you may simply provide a
         currency string; alternately, you may specify a locale. The preferred way is to use a
-        locale as this information is automatically detected and selected via the HTTP client
-        headers provided when a user accesses your application, and ensures the currency provided
-        will match their locale.
+        locale as this information is automatically detected and selected via the
+        <acronym>HTTP</acronym> client headers provided when a user accesses your application, and
+        ensures the currency provided will match their locale.
     </para>
 
     <note>

documentation/manual/en/tutorials/multiuser-sessions.xml

@@ -7,11 +7,12 @@
         <title>Introduction to Sessions</title>
 
         <para>
-            The success of the web is deeply rooted in the protocol that drives the web: HTTP. HTTP
-            over TCP is by its very nature stateless, which means that inherently the web is also
-            stateless. While this very aspect is one of the dominating factors for why the web has
-            become such a popular medium, it also causes an interesting problem for developers that
-            want to use the web as an application platform.
+            The success of the web is deeply rooted in the protocol that drives the web:
+            <acronym>HTTP</acronym>. <acronym>HTTP</acronym> over TCP is by its very nature
+            stateless, which means that inherently the web is also stateless. While this very aspect
+            is one of the dominating factors for why the web has become such a popular medium, it
+            also causes an interesting problem for developers that want to use the web as an
+            application platform.
         </para>
 
         <para>

documentation/manual/en/tutorials/quickstart-create-project.xml

@@ -231,8 +231,9 @@ phpSettings.display_errors = 1
         <para>
             Typically, you always need an <classname>IndexController</classname>, which is a
             fallback controller and which also serves the home page of the site, and an
-            <classname>ErrorController</classname>, which is used to indicate things such as HTTP
-            404 errors (controller or action not found) and HTTP 500 errors (application errors).
+            <classname>ErrorController</classname>, which is used to indicate things such as
+            <acronym>HTTP</acronym> 404 errors (controller or action not found) and
+            <acronym>HTTP</acronym> 500 errors (application errors).
         </para>
 
         <para>