You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hc.apache.org by gg...@apache.org on 2013/07/19 04:03:31 UTC
svn commit: r1504746 -
/httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml
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
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>
Re: svn commit: r1504746 - /httpcomponents/httpcore/trunk/src/docbkx/fundamentals.xml
Posted by sebb <se...@gmail.com>.
On 19 July 2013 03:03, <gg...@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