HTTP request message

Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20130719020331.901762388906@eris.apache.org>
References: <20130719020331.901762388906@eris.apache.org>
Date: Sat, 20 Jul 2013 22:58:21 +0100
Message-ID: 
 <CAOGo0VZi2od5xsmF_doAx+mVKA8XU4sP5nnxHCOZUyG8QH=VPg@mail.gmail.com>
Subject: Re: svn commit: r1504746 -
 /httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 19 July 2013 03:03,  <ggregory@apache.org> wrote:
> Author: ggregory
> Date: Fri Jul 19 02:03:31 2013
> New Revision: 1504746
>
> URL: http://svn.apache.org/r1504746
> Log:
> Minor edits from proof-reading (just got started, but done for now).
>
> Modified:
>     httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml
>
> Modified: httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml
> URL: http://svn.apache.org/viewvc/httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml?rev=1504746&r1=1504745&r2=1504746&view=diff
> ==============================================================================
> --- httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml (original)
> +++ httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml Fri Jul 19 02:03:31 2013
> @@ -36,7 +36,7 @@
>              enclose a content body.
>              </para>
>              <para>
> -            HttpCore defines the HTTP message object model to closely follow this definition and
> +            HttpCore defines the HTTP message object model to follow closely this definition and

That reads very oddly to me; the original read better.

The adverb is OK after the verb, but not when it comes between the
verb and the object.
I think it should be:

HttpCore defines the HTTP message object model to follow this
definition closely, and

>              provides extensive support for serialization (formatting) and deserialization
>              (parsing) of HTTP message elements.
>              </para>
> @@ -47,7 +47,7 @@
>                  <title>HTTP request message</title>
>                  <para>
>                  HTTP request is a message sent from the client to the server. The first line of
> -                that message includes the method to be applied to the resource, the identifier of
> +                that message includes the method to apply to the resource, the identifier of
>                  the resource, and the protocol version in use.
>                  </para>
>                  <programlisting><![CDATA[
> @@ -96,8 +96,8 @@ HTTP/1.1 200 OK
>                  <title>HTTP message common properties and methods</title>
>                  <para>
>                  An HTTP message can contain a number of headers describing properties of the
> -                message such as the content length, content type and so on. HttpCore provides
> -                methods to retrieve, add, remove and enumerate such headers.
> +                message such as the content length, content type, and so on. HttpCore provides
> +                methods to retrieve, add, remove, and enumerate such headers.
>                  </para>
>                  <programlisting><![CDATA[
>  HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,
> @@ -177,9 +177,9 @@ c3 = c
>   domain=localhost
>  ]]></programlisting>
>                  <para>
> -                HTTP headers get tokenized into individual header elements only on demand. HTTP
> +                HTTP headers are tokenized into individual header elements only on demand. HTTP
>                  headers received over an HTTP connection are stored internally as an array of
> -                characters and parsed lazily only when their properties are accessed.
> +                characters and parsed lazily only when you access their properties.
>                  </para>
>              </section>
>          </section>
> @@ -188,8 +188,8 @@ c3 = c
>              <para>
>              HTTP messages can carry a content entity associated with the request or response.
>              Entities can be found in some requests and in some responses, as they are optional.
> -            Requests that use entities are referred to as entity enclosing requests. The HTTP
> -            specification defines two entity enclosing methods: POST and PUT. Responses are
> +            Requests that use entities are referred to as entity-enclosing requests. The HTTP
> +            specification defines two entity-enclosing methods: POST and PUT. Responses are
>              usually expected to enclose a content entity. There are exceptions to this rule such
>              as responses to HEAD method and 204 No Content, 304 Not Modified, 205 Reset Content
>              responses.
> @@ -228,10 +228,10 @@ c3 = c
>                  </listitem>
>              </itemizedlist>
>              <para>
> -            This distinction is important for connection management with incoming entities. For
> -            entities that are created by an application and only sent using the HttpCore framework,
> +            This distinction is important for connection management with incoming entities. For
> +            an application that creates entities and only sends them using the HttpCore framework,
>              the difference between streamed and self-contained is of little importance. In that
> -            case, it is suggested to consider non-repeatable entities as streamed, and those that
> +            case, we suggest you consider non-repeatable entities as streamed, and those that
>              are repeatable as self-contained.
>              </para>
>              <section>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org