You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ortwin Glück <or...@nose.ch> on 2002/09/23 16:26:49 UTC
[PATCH][HttpClient] bug 12607
As suggested by Martin Elwin.
Patch is for .../src/java/
Should we throw an Exception instead of this:
} else {
// this was not CRLF, so now write '\r' + this char
baos.write('\r');
baos.write(b);
state = 0;
}
I mean having \r inside a chunk size field is illegal and thus a
protocol violation. Comments from the "real world"?
Re: [PATCH][HttpClient] bug 12607
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Ryan Hoegg wrote:
> Ortwin Glück wrote:
>
>> Ryan Hoegg wrote:
>>
>>> chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
>>> chunk-ext-name = token
>>> chunk-ext-val = token | quoted-string
>>> token = 1*<any CHAR except CTLs or separators>
>>>
>>> Since chunk-extension includes only tokens and an "=" I read this to
>>> say that neither \r or \n is allowed before the first CRLF in a chunk.
>>
>>
>>
>> But the quoted string may contain virtually ANY character, no?
>>
>> Legal:
>> 89ab;value\r\n
>> 89ab;key=value\r\n
>> 89ab;key=\"value\"\r\n
>> 89ab;key=\"line1\r\nline2\rline3\nline4\"\r\n
>>
>> Illegal:
>> 89ab;key=line1\rline2\r\n
>> 89ab;key=line1\r\nline2\r\n
>>
>> Since we ignore everything after the ; anyway, I don't want to parse
>> this, really. But we run into serious problems in the case where a
>> \r\n occurs within the quoted string!
>> I have never encountered a server using this in the real-world (but I
>> haven't seen enough servers). So once again: Has anybody ever see a
>> server using this?
>>
>> Odi
>
>
>
> I have never seen a server do this, but you are right about the
> quoted-string:
>
> quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
> quoted-pair = "\" CHAR
> qdtext = <any TEXT except <">>
>
> TEXT = <any OCTET except CTLs,
> but including LWS>
>
> So it seems that for each cunk-ext-val, we need to:
> 1) read the first char
> 2) if it is not a <">, proceed as we currently do
> 3) if it is, continue to read chars until a <"> or a <\> is reached
> 4) in the case of a <\>, skip the next character
> 5) in the case of a <">, ensure that we either have CRLF or <;>
> 6) if we have <;>, we read another <token=token|quoted-string> i.e.
> goto 1
>
> This is my reading of RFC2616.
>
> --
> Ryan Hoegg
> ISIS Networks
Sorry, left out:
LWS = [CRLF] 1*( SP | HT )
--
Ryan Hoegg
ISIS Networks
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Steve Downey <st...@netfolio.com>.
I was just thinking that. It's a little ugly since there are a lot of
exceptional productions, like <any TEXT except <">>, that would need to be
defined, but even those aren't hard.
On Thursday 26 September 2002 08:38 am, Jeff Dever wrote:
> The text string parsing is really not fun. One day we should go to regex
> pattern matching, which is not to difficult to construct from the BNF in
> the relevent RFCs. It will also be easier to handle
> non-standard/malformatted responses.
>
> Perhaps that will be HttpClient 3.0 ...
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
As you probably suspected, the server's response doesn't seem to be
showing any extra stuff in the chunk-size section. In fact, I think the
problem is that the server is giving a Content-Length header as well as
chunking. From RFC2616:
If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
This is what my sniffer shows as the server's response:
HTTP/1.1 200 OK
Date: Sun, 29 Sep 2002 18:20:42 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.2.2
X-Powered-By: PHP/4.2.2
Transfer-Encoding: chunked
Content-Type: text/xml
Content-length: 338
152
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>1</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Unknown method</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
0
And this is what UrlPostMethod.getResponseBodyAsString() is returning:
152
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>1</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Unknown method</string></value>
</member>
</struct>
</value>
</fault>
</methodResp
I'll see if I can't put together a bug report and patch and post it to
bugzilla.
--
Ryan Hoegg
ISIS Networks
Ortwin Glück wrote:
> Could you post the server's response?
>
> Ryan Hoegg wrote:
>
>> Although it seems we will be going to BNF as a regex someday, I am
>> suspicious that this very issue is causing incompatibility with a
>> HTTP 1.1 server I am trying to access. So I may make a stab at
>> parsing this chunk size thing as I wrote below. Am I right in
>> assuming this patch should go to bug 12607?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
Could you post the server's response?
Ryan Hoegg wrote:
> Although it seems we will be going to BNF as a regex someday, I am
> suspicious that this very issue is causing incompatibility with a HTTP
> 1.1 server I am trying to access. So I may make a stab at parsing this
> chunk size thing as I wrote below. Am I right in assuming this patch
> should go to bug 12607?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Although it seems we will be going to BNF as a regex someday, I am
suspicious that this very issue is causing incompatibility with a HTTP
1.1 server I am trying to access. So I may make a stab at parsing this
chunk size thing as I wrote below. Am I right in assuming this patch
should go to bug 12607?
--
Ryan Hoegg
ISIS Networks
Ortwin Glück wrote:
> LWS = [CRLF] 1*( SP | HT )
>
> Damn. We must parse this shit....
>
> Ryan Hoegg wrote:
>
>> I have never seen a server do this, but you are right about the
>> quoted-string:
>>
>> quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
>> quoted-pair = "\" CHAR
>> qdtext = <any TEXT except <">>
>>
>> TEXT = <any OCTET except CTLs,
>> but including LWS>
>>
>> So it seems that for each cunk-ext-val, we need to:
>> 1) read the first char
>> 2) if it is not a <">, proceed as we currently do
>> 3) if it is, continue to read chars until a <"> or a <\> is reached
>> 4) in the case of a <\>, skip the next character
>> 5) in the case of a <">, ensure that we either have CRLF or <;>
>> 6) if we have <;>, we read another <token=token|quoted-string> i.e.
>> goto 1
>>
>> This is my reading of RFC2616.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Jeff Dever <js...@sympatico.ca>.
Ok, done. Its targeted for 2.1 so we can discuss it later.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13031
Ortwin Glück wrote:
> File it as a feature-bug maybe?
>
> Jeff Dever wrote:
> > The text string parsing is really not fun. One day we should go to regex
> > pattern matching, which is not to difficult to construct from the BNF in the
> > relevent RFCs. It will also be easier to handle non-standard/malformatted
> > responses.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
File it as a feature-bug maybe?
Jeff Dever wrote:
> The text string parsing is really not fun. One day we should go to regex
> pattern matching, which is not to difficult to construct from the BNF in the
> relevent RFCs. It will also be easier to handle non-standard/malformatted
> responses.
>
> Perhaps that will be HttpClient 3.0 ...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Jeff Dever <js...@sympatico.ca>.
The text string parsing is really not fun. One day we should go to regex
pattern matching, which is not to difficult to construct from the BNF in the
relevent RFCs. It will also be easier to handle non-standard/malformatted
responses.
Perhaps that will be HttpClient 3.0 ...
Ortwin Glück wrote:
> LWS = [CRLF] 1*( SP | HT )
>
> Damn. We must parse this shit....
>
> Ryan Hoegg wrote:
>
> > I have never seen a server do this, but you are right about the
> > quoted-string:
> >
> > quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
> > quoted-pair = "\" CHAR
> > qdtext = <any TEXT except <">>
> >
> > TEXT = <any OCTET except CTLs,
> > but including LWS>
> >
> > So it seems that for each cunk-ext-val, we need to:
> > 1) read the first char
> > 2) if it is not a <">, proceed as we currently do
> > 3) if it is, continue to read chars until a <"> or a <\> is reached
> > 4) in the case of a <\>, skip the next character
> > 5) in the case of a <">, ensure that we either have CRLF or <;>
> > 6) if we have <;>, we read another <token=token|quoted-string> i.e. goto 1
> >
> > This is my reading of RFC2616.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
Done.
Ortwin Glück wrote:
> LWS = [CRLF] 1*( SP | HT )
>
> Damn. We must parse this shit....
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
hardturmstrasse 171 [email] ortwin.glueck@nose.ch
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
LWS = [CRLF] 1*( SP | HT )
Damn. We must parse this shit....
Ryan Hoegg wrote:
> I have never seen a server do this, but you are right about the
> quoted-string:
>
> quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
> quoted-pair = "\" CHAR
> qdtext = <any TEXT except <">>
>
> TEXT = <any OCTET except CTLs,
> but including LWS>
>
> So it seems that for each cunk-ext-val, we need to:
> 1) read the first char
> 2) if it is not a <">, proceed as we currently do
> 3) if it is, continue to read chars until a <"> or a <\> is reached
> 4) in the case of a <\>, skip the next character
> 5) in the case of a <">, ensure that we either have CRLF or <;>
> 6) if we have <;>, we read another <token=token|quoted-string> i.e. goto 1
>
> This is my reading of RFC2616.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Ortwin Glück wrote:
> Ryan Hoegg wrote:
>
>> chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
>> chunk-ext-name = token
>> chunk-ext-val = token | quoted-string
>> token = 1*<any CHAR except CTLs or separators>
>>
>> Since chunk-extension includes only tokens and an "=" I read this to
>> say that neither \r or \n is allowed before the first CRLF in a chunk.
>
>
> But the quoted string may contain virtually ANY character, no?
>
> Legal:
> 89ab;value\r\n
> 89ab;key=value\r\n
> 89ab;key=\"value\"\r\n
> 89ab;key=\"line1\r\nline2\rline3\nline4\"\r\n
>
> Illegal:
> 89ab;key=line1\rline2\r\n
> 89ab;key=line1\r\nline2\r\n
>
> Since we ignore everything after the ; anyway, I don't want to parse
> this, really. But we run into serious problems in the case where a
> \r\n occurs within the quoted string!
> I have never encountered a server using this in the real-world (but I
> haven't seen enough servers). So once again: Has anybody ever see a
> server using this?
>
> Odi
I have never seen a server do this, but you are right about the
quoted-string:
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
quoted-pair = "\" CHAR
qdtext = <any TEXT except <">>
TEXT = <any OCTET except CTLs,
but including LWS>
So it seems that for each cunk-ext-val, we need to:
1) read the first char
2) if it is not a <">, proceed as we currently do
3) if it is, continue to read chars until a <"> or a <\> is reached
4) in the case of a <\>, skip the next character
5) in the case of a <">, ensure that we either have CRLF or <;>
6) if we have <;>, we read another <token=token|quoted-string> i.e. goto 1
This is my reading of RFC2616.
--
Ryan Hoegg
ISIS Networks
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
Jeff Dever wrote:
> So \n and \r are in the range of CTL and are therefore not valid in the
> chunk-extension.
All right, cool! So I am gonne change the patch to throw an exception
and check it in. Test case will be included.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Jeff Dever <js...@sympatico.ca>.
Also from RFC2616:
TEXT = <any OCTET except CTLs,
but including LWS>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
So \n and \r are in the range of CTL and are therefore not valid in the
chunk-extension.
Ortwin Glück wrote:
> Ryan Hoegg wrote:
> > chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
> > chunk-ext-name = token
> > chunk-ext-val = token | quoted-string
> > token = 1*<any CHAR except CTLs or separators>
> >
> > Since chunk-extension includes only tokens and an "=" I read this to say
> > that neither \r or \n is allowed before the first CRLF in a chunk.
>
> But the quoted string may contain virtually ANY character, no?
>
> Legal:
> 89ab;value\r\n
> 89ab;key=value\r\n
> 89ab;key=\"value\"\r\n
> 89ab;key=\"line1\r\nline2\rline3\nline4\"\r\n
>
> Illegal:
> 89ab;key=line1\rline2\r\n
> 89ab;key=line1\r\nline2\r\n
>
> Since we ignore everything after the ; anyway, I don't want to parse
> this, really. But we run into serious problems in the case where a \r\n
> occurs within the quoted string!
> I have never encountered a server using this in the real-world (but I
> haven't seen enough servers). So once again: Has anybody ever see a
> server using this?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
Ryan Hoegg wrote:
> chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
> chunk-ext-name = token
> chunk-ext-val = token | quoted-string
> token = 1*<any CHAR except CTLs or separators>
>
> Since chunk-extension includes only tokens and an "=" I read this to say
> that neither \r or \n is allowed before the first CRLF in a chunk.
But the quoted string may contain virtually ANY character, no?
Legal:
89ab;value\r\n
89ab;key=value\r\n
89ab;key=\"value\"\r\n
89ab;key=\"line1\r\nline2\rline3\nline4\"\r\n
Illegal:
89ab;key=line1\rline2\r\n
89ab;key=line1\r\nline2\r\n
Since we ignore everything after the ; anyway, I don't want to parse
this, really. But we run into serious problems in the case where a \r\n
occurs within the quoted string!
I have never encountered a server using this in the real-world (but I
haven't seen enough servers). So once again: Has anybody ever see a
server using this?
Odi
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I went back to RFC2616 to find this (3.6.1):
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
and this (2.2):
token = 1*<any CHAR except CTLs or separators>
Since chunk-extension includes only tokens and an "=" I read this to say
that neither \r or \n is allowed before the first CRLF in a chunk.
--
Ryan Hoegg
ISIS Networks
Ortwin Glück wrote:
> Not sure if single \n or \r is allowed here or not. Maybe leave it as
> it is.
>
> "Real world guys" anyone?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Ortwin Glück <or...@nose.ch>.
Jeff Dever wrote:
> Well it looks like the else is trying to "correct" the error where
> there is a spurious '\r' by writing the full /r/n to the output
> stream and trys again.
Not quite.
This piece of code is used to grab the chunk length of the next chunk
from the stream which is on a line that looks like:
1b4; some textual comment\r\n
A hex value followed by an optional semicolon and a comment. The \r\n is
required. Binary data is not allowed after the semicolon.
Normally this code omits the trailing \r\n in the result. But if it
finds a \r NOT followed by a \n it would include the \r in the result
and continue until a \r\n is found.
> But it doesn't try to correct for a '\n' in
> the same way (it just writes it out in state 0). This does not look
> particularly valuable.
This is not necessary. A single \n would be included in the result
automatically.
> Is it possible that we would be reading over some binary data that
> might have some valid \r or \n hex values?
No binary data allowed here.
> In that case we should
> try to correct for the spurious '\n' as well ... Otherwise throwing
> a IOException seems prudent.
Not sure if single \n or \r is allowed here or not. Maybe leave it as it is.
"Real world guys" anyone?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH][HttpClient] bug 12607
Posted by Jeff Dever <js...@sympatico.ca>.
Well it looks like the else is trying to "correct" the error where there is a spurious '\r' by writing the full /r/n to
the output stream and trys again. But it doesn't try to correct for a '\n' in the same way (it just writes it out in
state 0). This does not look particularly valuable.
Is it possible that we would be reading over some binary data that might have some valid \r or \n hex values? In that
case we should try to correct for the spurious '\n' as well ... Otherwise throwing a IOException seems prudent.
Ortwin Glück wrote:
> As suggested by Martin Elwin.
>
> Patch is for .../src/java/
>
> Should we throw an Exception instead of this:
> } else {
> // this was not CRLF, so now write '\r' + this char
> baos.write('\r');
> baos.write(b);
> state = 0;
> }
>
> I mean having \r inside a chunk size field is illegal and thus a
> protocol violation. Comments from the "real world"?
>
> ------------------------------------------------------------------------
> ? patch.diff
> Index: org/apache/commons/httpclient/ChunkedInputStream.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java,v
> retrieving revision 1.3
> diff -u -w -r1.3 ChunkedInputStream.java
> --- org/apache/commons/httpclient/ChunkedInputStream.java 12 Sep 2002 11:36:45 -0000 1.3
> +++ org/apache/commons/httpclient/ChunkedInputStream.java 23 Sep 2002 14:13:24 -0000
> @@ -134,7 +134,7 @@
> nextChunk();
> if (eof) return -1;
> }
> - len = Math.min(len, chunkSize);
> + len = Math.min(len, chunkSize - pos);
> int count = in.read(b, off, len);
> pos += count;
> return count;
> @@ -172,22 +172,30 @@
> */
> private static int getChunkSizeFromInputStream(final InputStream in) throws IOException {
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> - int b = in.read();
> int state = 0;
> while (state != 2) {
> + int b = in.read();
> if (b == -1) throw new IOException("chunked stream ended unexpectedly");
> switch (state) {
> case 0:
> - if (b == '\r') state = 1;
> + if (b == '\r') {
> + state = 1;
> + } else {
> + baos.write(b);
> + }
> break;
> case 1:
> - if (b == '\n') state = 2;
> - else state = 0;
> + if (b == '\n') {
> + state = 2;
> + } else {
> + // this was not CRLF, so now write '\r' + this char
> + baos.write('\r');
> + baos.write(b);
> + state = 0;
> + }
> break;
> default: throw new RuntimeException("assertion failed");
> }
> - if (state == 0) baos.write(b);
> - if (state != 2) b = in.read();
> }
>
> //parse data
> @@ -199,7 +207,7 @@
>
> int result;
> try {
> - result = Integer.parseInt(dataString, 16);
> + result = Integer.parseInt(dataString.trim(), 16);
> } catch(NumberFormatException e) {
> throw new IOException("Bad chunk size: "+dataString);
> }
> Index: org/apache/commons/httpclient/HttpConnection.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
> retrieving revision 1.20
> diff -u -w -r1.20 HttpConnection.java
> --- org/apache/commons/httpclient/HttpConnection.java 8 Sep 2002 05:35:09 -0000 1.20
> +++ org/apache/commons/httpclient/HttpConnection.java 23 Sep 2002 14:13:26 -0000
> @@ -455,7 +455,7 @@
> */
> public InputStream getResponseInputStream(HttpMethod method)
> throws IOException, IllegalStateException {
> - log.trace("enter HttpConnection.getRequestOutputStream(HttpMethod)");
> + log.trace("enter HttpConnection.getResponseInputStream(HttpMethod)");
> assertOpen();
> return _input;
> }
> Index: org/apache/commons/httpclient/WireLogInputStream.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/WireLogInputStream.java,v
> retrieving revision 1.3
> diff -u -w -r1.3 WireLogInputStream.java
>
> ------------------------------------------------------------------------
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> ------------------------------------------------------------------------
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>