You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by "Morris, Chris" <Ch...@epsilon.com> on 2007/09/26 20:53:20 UTC
HTTP Response contains headers last
Hi all,
I'm working with an API that returns the HTTP Response Headers after the
response body. This confuses the HTTPClient and PostMethod into
thinking that there is no body. Is there a way for me to get direct
access to the response input stream so that I can parse it out myself?
Thanks!
Chris Morris
The information contained in this communication is
confidential, and is intended only for the sole use of
the recipient named above. If the reader of this
message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have
received this communication in error, please re-send
this communication to the sender and delete the original
message or any copy of it from your computer system.
Thank you.
Re: HTTP Response contains headers last
Posted by Roland Weber <os...@dubioso.net>.
Hi Chris,
> Good point! I'll ask the folks who own the API that I'm accessing to
> move the record count and other API-specific status information to the
> HTTP response footers. That seems like a reasonable request. What do
> you think my chances are? ;)
Whoever had that idea in the first place has not the
least clue about protocol design... it's like arguing
architecture with someone who's understanding of a
house is "four walls and a roof":
- Eh, Sir... the roof goes on top.
- Says who? I need protection against creeping cold
on the floor, so I put the roof at the bottom. Ha!
I guess your best chances are to suggest that the record count is
not put into headers or trailers, but added as the last line of
the message body. There, the application can parse it out.
Trailers are non-trivial to implement, and your folks seem to
use a hand-crafted implementation... I cannot imagine that any
standard HTTP implementation would even allow to send the body
before the entity.
If you can't convince them, the best way to make it work is
still HttpClient. You can install a custom socket factory. And
in your custom socket implementation, you can just buffer the
whole response and then deliver it to the caller in the correct
order: response line, headers, empty line, entity.
good luck,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: HTTP Response contains headers last
Posted by "Morris, Chris" <Ch...@epsilon.com>.
Good point! I'll ask the folks who own the API that I'm accessing to
move the record count and other API-specific status information to the
HTTP response footers. That seems like a reasonable request. What do
you think my chances are? ;)
Chris Morris
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Thursday, September 27, 2007 10:56 AM
To: HttpClient User Discussion
Subject: Re: HTTP Response contains headers last
Hi Morris,
> I'm working on a workaround using the HttpURLConnection
(java.util.net)
> class. It's probably no where near as elegant or bullet proof as
> HttpClient, but at least I have direct access to the input stream so
> that I can parse it myself.
You don't. At least not with the public API. HttpURLConnection
will also automatically read in the head section. That's necessary
to determine whether there is a body in the first place, and to
evaluate the transfer encoding. If the transfer encoding is "chunked",
HttpURLConnection installs a layered stream that takes care of
decoding the chunks, just as HttpClient does.
> If you're interested, the server actually sends the headers last on
> purpose. Reason being, it includes a header field containing a record
> count.
A guy called Peter Jackson once shot a movie called "Braindead".
Readers of this mail are welcome to decide for themselves whether
this remark is off-topic. The movie is funny, by the way. If you
like splatter.
RFC 2616, that is HTTP 1.1, explicitly allows for footers (or
rather trailers) in section 3.6.1 and elsewhere. These have to
be properly announced in the headers, and can only be used in
combination with chunked encoding. They might get lost by proxies.
But no proxy would relay what your server is sending anyway.
If folks have to invent their own data format, they should just
do so. Instead of pretending to "tweak" a standard. How is any
receiver supposed to reliably detect the end of the entity with
this <censored>? They have to scan the input, and then they might
as well count the records themselves while scanning. *shiver*
> I don't think it's worth all the trouble that this has caused
> me. I'd much rather make a second API call to get the record count
then
> have to deal with this, but, that's the way it is for now!
Sincere condolences,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
The information contained in this communication is
confidential, and is intended only for the sole use of
the recipient named above. If the reader of this
message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have
received this communication in error, please re-send
this communication to the sender and delete the original
message or any copy of it from your computer system.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: HTTP Response contains headers last
Posted by Roland Weber <os...@dubioso.net>.
Hi Morris,
> I'm working on a workaround using the HttpURLConnection (java.util.net)
> class. It's probably no where near as elegant or bullet proof as
> HttpClient, but at least I have direct access to the input stream so
> that I can parse it myself.
You don't. At least not with the public API. HttpURLConnection
will also automatically read in the head section. That's necessary
to determine whether there is a body in the first place, and to
evaluate the transfer encoding. If the transfer encoding is "chunked",
HttpURLConnection installs a layered stream that takes care of
decoding the chunks, just as HttpClient does.
> If you're interested, the server actually sends the headers last on
> purpose. Reason being, it includes a header field containing a record
> count.
A guy called Peter Jackson once shot a movie called "Braindead".
Readers of this mail are welcome to decide for themselves whether
this remark is off-topic. The movie is funny, by the way. If you
like splatter.
RFC 2616, that is HTTP 1.1, explicitly allows for footers (or
rather trailers) in section 3.6.1 and elsewhere. These have to
be properly announced in the headers, and can only be used in
combination with chunked encoding. They might get lost by proxies.
But no proxy would relay what your server is sending anyway.
If folks have to invent their own data format, they should just
do so. Instead of pretending to "tweak" a standard. How is any
receiver supposed to reliably detect the end of the entity with
this <censored>? They have to scan the input, and then they might
as well count the records themselves while scanning. *shiver*
> I don't think it's worth all the trouble that this has caused
> me. I'd much rather make a second API call to get the record count then
> have to deal with this, but, that's the way it is for now!
Sincere condolences,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: HTTP Response contains headers last
Posted by "Morris, Chris" <Ch...@epsilon.com>.
Thanks Roland! That aligns with my conclusion as well.
I'm working on a workaround using the HttpURLConnection (java.util.net)
class. It's probably no where near as elegant or bullet proof as
HttpClient, but at least I have direct access to the input stream so
that I can parse it myself.
If you're interested, the server actually sends the headers last on
purpose. Reason being, it includes a header field containing a record
count. I don't think it's worth all the trouble that this has caused
me. I'd much rather make a second API call to get the record count then
have to deal with this, but, that's the way it is for now!
Thanks again for your help!
Chris Morris
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Thursday, September 27, 2007 10:16 AM
To: HttpClient User Discussion
Subject: Re: HTTP Response contains headers last
Hello Chris,
that server is not only sending the headers last.
It is sending the whole head section of the HTTP
response after the body. That is not HTTP at all.
Not even close.
Even though the supposed body is listed in the
output as "headers", that's not what HttpClient
makes of it. HttpClient simply skips garbage
lines at the beginning of a response, until it
finds the line starting with "HTTP/1.1". Then,
it reads in the head section. And then, it would
try to read the body, except that there is none.
There is not even the required empty line that
terminates the head section.
I have two explanations for this. One: the server
is using persistent connections, but gets confused
by something the client does. That could happen if
you use the SimpleHttpConnectionManager from multiple
threads. But if that log is the full log of a test
run, that's not what happens.
Two: the server is totally screwed and has no idea
of what HTTP specifies. In that case, you're best
off by connecting directly to the server using a
Socket. I'm sorry, but that behavior is way too far
off to tweak HttpClient into tolerance.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
The information contained in this communication is
confidential, and is intended only for the sole use of
the recipient named above. If the reader of this
message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have
received this communication in error, please re-send
this communication to the sender and delete the original
message or any copy of it from your computer system.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: HTTP Response contains headers last
Posted by Roland Weber <os...@dubioso.net>.
Hello Chris,
that server is not only sending the headers last.
It is sending the whole head section of the HTTP
response after the body. That is not HTTP at all.
Not even close.
Even though the supposed body is listed in the
output as "headers", that's not what HttpClient
makes of it. HttpClient simply skips garbage
lines at the beginning of a response, until it
finds the line starting with "HTTP/1.1". Then,
it reads in the head section. And then, it would
try to read the body, except that there is none.
There is not even the required empty line that
terminates the head section.
I have two explanations for this. One: the server
is using persistent connections, but gets confused
by something the client does. That could happen if
you use the SimpleHttpConnectionManager from multiple
threads. But if that log is the full log of a test
run, that's not what happens.
Two: the server is totally screwed and has no idea
of what HTTP specifies. In that case, you're best
off by connecting directly to the server using a
Socket. I'm sorry, but that behavior is way too far
off to tweak HttpClient into tolerance.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: HTTP Response contains headers last
Posted by "Morris, Chris" <Ch...@epsilon.com>.
Thanks Roland.
I tried treating them as footers to no avail. I still don't get access
to the actual body of the response.
Here's the wire log. As you can see from below, the "data" portion of
the response (which should be considered the body) is being skipped over
to get to the headers. The problem is that attempting to grab the data
as headers, footers or body is not working. It's like the method is
throwing those lines away (but the wire output thinks they are header
rows).
[INFO] DreamAPIRequest - -Extracting activity for campaign: test
mailing: test01
[DEBUG] HttpClient - -Java version: 1.5.0_10
[DEBUG] HttpClient - -Java vendor: Sun Microsystems Inc.
[DEBUG] HttpClient - -Java class path: C:\Documents and
Settings\cmorris\workspace\AMI_2.0_Local\target;C:\Documents and
Settings\cmorris\workspace\AMI_2.0_Local\target\classes;C:\Documents and
Settings\cmorris\.m2\repository\commons-codec\commons-codec\1.2\commons-
codec-1.2.jar;C:\Documents and
Settings\cmorris\.m2\repository\commons-httpclient\commons-httpclient\3.
0.1\commons-httpclient-3.0.1.jar;C:\Documents and
Settings\cmorris\.m2\repository\commons-io\commons-io\1.3.1\commons-io-1
.3.1.jar;C:\Documents and
Settings\cmorris\.m2\repository\commons-logging\commons-logging\1.0.3\co
mmons-logging-1.0.3.jar;C:\Documents and
Settings\cmorris\.m2\repository\commons-vfs\commons-vfs\1.0\commons-vfs-
1.0.jar;C:\Documents and
Settings\cmorris\.m2\repository\jdom\jdom\1.0\jdom-1.0.jar;C:\Documents
and
Settings\cmorris\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar;C:\Doc
uments and
Settings\cmorris\workspace\AMI_2.0_Local\jar\commons-httpclient-3.0.1.ja
r;C:\Documents and
Settings\cmorris\workspace\AMI_2.0_Local\jar\commons-logging-1.0.3.jar;C
:\Documents and
Settings\cmorris\workspace\AMI_2.0_Local\jar\commons-vfs-20070719.jar;C:
\Documents and
Settings\cmorris\workspace\AMI_2.0_Local\jar\jdom-1.0.jar;C:\Documents
and Settings\cmorris\workspace\AMI_2.0_Local\jar\xerces.jar;C:\Documents
and
Settings\cmorris\workspace\AMI_2.0_Local\jar\commons-codec-1.2.jar;C:\Do
cuments and
Settings\cmorris\workspace\AMI_2.0_Local\jar\commons-net-1.4.1.jar;C:\Do
cuments and Settings\cmorris\workspace\AMI_2.0_Local\jar\jsch-0.1.32.jar
[DEBUG] HttpClient - -Operating system name: Windows XP
[DEBUG] HttpClient - -Operating system architecture: x86
[DEBUG] HttpClient - -Operating system version: 5.1
[DEBUG] HttpClient - -SUN 1.5: SUN (DSA key/parameter generation; DSA
signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS
keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection
CertStores)
[DEBUG] HttpClient - -SunRsaSign 1.5: Sun RSA signature provider
[DEBUG] HttpClient - -SunJSSE 1.5: Sun JSSE provider(PKCS12, SunX509
key/trust factories, SSLv3, TLSv1)
[DEBUG] HttpClient - -SunJCE 1.5: SunJCE Provider (implements RSA, DES,
Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
[DEBUG] HttpClient - -SunJGSS 1.0: Sun (Kerberos v5)
[DEBUG] HttpClient - -SunSASL 1.5: Sun SASL provider(implements client
mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5; server
mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5)
[DEBUG] DefaultHttpParams - -Set parameter http.useragent = Jakarta
Commons-HttpClient/3.0.1
[DEBUG] DefaultHttpParams - -Set parameter http.protocol.version =
HTTP/1.1
[DEBUG] DefaultHttpParams - -Set parameter http.connection-manager.class
= class org.apache.commons.httpclient.SimpleHttpConnectionManager
[DEBUG] DefaultHttpParams - -Set parameter http.protocol.cookie-policy =
rfc2109
[DEBUG] DefaultHttpParams - -Set parameter http.protocol.element-charset
= US-ASCII
[DEBUG] DefaultHttpParams - -Set parameter http.protocol.content-charset
= ISO-8859-1
[DEBUG] DefaultHttpParams - -Set parameter http.method.retry-handler =
org.apache.commons.httpclient.DefaultHttpMethodRetryHandler@1198891
[DEBUG] DefaultHttpParams - -Set parameter http.dateparser.patterns =
[EEE, dd MMM yyyy HH:mm:ss zzz, EEEE, dd-MMM-yy HH:mm:ss zzz, EEE MMM d
HH:mm:ss yyyy, EEE, dd-MMM-yyyy HH:mm:ss z, EEE, dd-MMM-yyyy HH-mm-ss z,
EEE, dd MMM yy HH:mm:ss z, EEE dd-MMM-yyyy HH:mm:ss z, EEE dd MMM yyyy
HH:mm:ss z, EEE dd-MMM-yyyy HH-mm-ss z, EEE dd-MMM-yy HH:mm:ss z, EEE dd
MMM yy HH:mm:ss z, EEE,dd-MMM-yy HH:mm:ss z, EEE,dd-MMM-yyyy HH:mm:ss z,
EEE, dd-MM-yyyy HH:mm:ss z]
[INFO] HttpAPIRequest - -postRequest posting to:
http://dweb.bfi0.com:9000/api/ActivityDownload.mpl
[INFO] HttpAPIRequest - -HTTP Post contains the following parameters:
[INFO] HttpAPIRequest - -parameter: headers_first = 0
[INFO] HttpAPIRequest - -parameter: client_name = xxxxxxxxxxxx
[INFO] HttpAPIRequest - -parameter: client_token = xxxxxxxxxxxxx
[INFO] HttpAPIRequest - -parameter: output_field_delimiter = ||
[INFO] HttpAPIRequest - -parameter: campaign_name = test
[INFO] HttpAPIRequest - -parameter: mailing_name = test01
[INFO] HttpAPIRequest - -parameter: start_date = 20070901
[INFO] HttpAPIRequest - -parameter: end_date = 20070930
[INFO] HttpAPIRequest - -parameter: ret_mod_name = Y
[INFO] HttpAPIRequest - -parameter: ret_link_name = Y
[INFO] HttpAPIRequest - -parameter: profile_field_names = CUST_ID
[DEBUG] HttpConnection - -Open connection to xxxx.xxxx.xxx:9000
[DEBUG] header - ->> "POST /api/ActivityDownload.mpl HTTP/1.1[\r][\n]"
[DEBUG] HttpMethodBase - -Adding Host request header
[DEBUG] HttpMethodBase - -Default charset used: ISO-8859-1
[DEBUG] HttpMethodBase - -Default charset used: ISO-8859-1
[DEBUG] header - ->> "User-Agent: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7[\r][\n]"
[DEBUG] header - ->> "Keep-Alive: 300[\r][\n]"
[DEBUG] header - ->> "Connection: keep-alive[\r][\n]"
[DEBUG] header - ->> "Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
n;q=0.8,image/png,*/*;q=0.5[\r][\n]"
[DEBUG] header - ->> "Accept-Language: en-us,en;q=0.5[\r][\n]"
[DEBUG] header - ->> "Accept-Encoding: gzip,deflate[\r][\n]"
[DEBUG] header - ->> "Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7[\r][\n]"
[DEBUG] header - ->> "Host: xxxx.xxx.xxx:9000[\r][\n]"
[DEBUG] header - ->> "Content-Length: 238[\r][\n]"
[DEBUG] header - ->> "Content-Type:
application/x-www-form-urlencoded[\r][\n]"
[DEBUG] header - ->> "[\r][\n]"
[DEBUG] EntityEnclosingMethod - -Request body sent
[DEBUG] header - -<<
"test01||email2@foo.com||email2@foo.com||HVWB||H||G||DEF||||||||1||20070
911 111040||[\r][\n]"
[DEBUG] header - -<<
"test01||email3@foo.com||email3@foo.com||HVWB||H||G||DEF||||||||1||20070
911 111602||[\r][\n]"
[DEBUG] header - -<<
"test01||email3@foo.com||email3@foo.com||HVWB||H||G||DEF||||||||0||20070
911 111602||[\r][\n]"
[DEBUG] header - -<<
"test01||email3@foo.com||email3@foo.com||HVWB||H||G||DEF||||||||0||20070
911 111602||[\r][\n]"
[DEBUG] header - -<<
"test01||email3@foo.com||email3@foo.com||HVWB||H||G||DEF||||||||0||20070
911 111603||[\r][\n]"
[DEBUG] header - -<<
"test01||email2@foo.com||email2@foo.com||SEND||H||S||1||||||||1||2007091
1 110746||[\r][\n]"
[DEBUG] header - -<<
"test01||email4@foo.com||email4@foo.com||SEND||H||S||1||||||||1||2007091
1 110748||[\r][\n]"
[DEBUG] header - -<<
"test01||email3@foo.com||email3@foo.com||SEND||H||S||1||||||||1||2007091
1 110749||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||SEND||H||S||1||||||||1||2007091
1 110751||[\r][\n]"
[DEBUG] header - -<<
"test01||email5@foo.com||email5@foo.com||SEND||H||S||1||||||||1||2007091
1 110752||[\r][\n]"
[DEBUG] header - -<<
"test01||email2@foo.com||email2@foo.com||HVWB||H||R||280988||http://www.
epsiloninteractive.com||TOPLEVEL||test_linkname_html||1||20070911
111120||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||G||DEF||||||||0||20070
912 152737||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||R||280988||http://www.
epsiloninteractive.com||TOPLEVEL||test_linkname_html||0||20070912
152742||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||G||DEF||||||||1||20070
913 221549||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||R||280988||http://www.
epsiloninteractive.com||TOPLEVEL||test_linkname_html||1||20070913
221553||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||R||280988||http://www.
epsiloninteractive.com||TOPLEVEL||test_linkname_html||0||20070913
221602||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||G||DEF||||||||0||20070
914 102710||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||G||DEF||||||||0||20070
918 165151||[\r][\n]"
[DEBUG] header - -<<
"test01||email5@foo.com||email5@foo.com||HVWB||H||G||DEF||||||||1||20070
918 170651||[\r][\n]"
[DEBUG] header - -<<
"test01||email5@foo.com||email5@foo.com||HVWB||H||G||DEF||||||||0||20070
918 170651||[\r][\n]"
[DEBUG] header - -<<
"test01||email4@foo.com||email4@foo.com||HVWB||H||G||DEF||||||||1||20070
918 172650||[\r][\n]"
[DEBUG] header - -<<
"test01||email4@foo.com||email4@foo.com||HVWB||H||G||DEF||||||||0||20070
918 172650||[\r][\n]"
[DEBUG] header - -<<
"test01||email2@foo.com||email2@foo.com||HVWB||H||G||DEF||||||||0||20070
918 172743||[\r][\n]"
[DEBUG] header - -<<
"test01||email4@foo.com||email4@foo.com||HVWB||T||C||DEF||||||||1||20070
918 174925||[\r][\n]"
[DEBUG] header - -<<
"test01||email4@foo.com||email4@foo.com||HVWB||T||O||DEF||||||||1||20070
918 175044||[\r][\n]"
[DEBUG] header - -<<
"test01||email2@foo.com||email2@foo.com||SEND||H||S||1||||||||0||2007091
8 170117||[\r][\n]"
[DEBUG] header - -<<
"test01||email4@foo.com||email4@foo.com||SEND||H||S||1||||||||0||2007091
8 170122||[\r][\n]"
[DEBUG] header - -<<
"test01||email3@foo.com||email3@foo.com||SEND||H||S||1||||||||0||2007091
8 170124||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||SEND||H||S||1||||||||0||2007091
8 170125||[\r][\n]"
[DEBUG] header - -<<
"test01||email5@foo.com||email5@foo.com||SEND||H||S||1||||||||0||2007091
8 170126||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||G||DEF||||||||0||20070
918 190149||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||R||280988||http://www.
epsiloninteractive.com||TOPLEVEL||test_linkname_html||0||20070918
190154||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||R||331121||http://www.
epsiloninteractive.com||TEST_MODULE||test_module_link_name_html||1||2007
0918 190158||[\r][\n]"
[DEBUG] header - -<<
"test01||Email1@foo.com||email1@foo.com||HVWB||H||G||DEF||||||||0||20070
919 113605||[\r][\n]"
[DEBUG] header - -<< "HTTP/1.1 200 OK[\r][\n]"
[DEBUG] header - -<< "Date: Thu, 27 Sep 2007 15:38:28 GMT[\r][\n]"
[DEBUG] header - -<< "Server: Apache[\r][\n]"
[DEBUG] header - -<< "BFI-Status: OK[\r][\n]"
[DEBUG] header - -<< "BFI-Status-String: [\r][\n]"
[DEBUG] header - -<< "BFI-Number-Records: 34[\r][\n]"
[DEBUG] header - -<< "Connection: close[\r][\n]"
[DEBUG] header - -<< "Transfer-Encoding: chunked[\r][\n]"
[DEBUG] header - -<< "Content-Type: text/plain[\r][\n]"
[WARN] HttpMethodBase - -Going to buffer response body of large or
unknown size. Using getResponseBodyAsStream instead is
recommended.test||
[DEBUG] HttpMethodBase - -Buffering response body
[DEBUG] HttpMethodBase - -Should close connection in response to
directive: close
[DEBUG] HttpConnection - -Releasing connection back to connection
manager.
[INFO] HttpAPIRequest - -postRequest received the following response:
HTTP/1.1 200 OK
[DEBUG] HttpAPIRequest - -response header: Date: Thu, 27 Sep 2007
15:38:28 GMT
[DEBUG] HttpAPIRequest - -response header: Server: Apache
[DEBUG] HttpAPIRequest - -response header: BFI-Status: OK
[DEBUG] HttpAPIRequest - -response header: BFI-Status-String:
[DEBUG] HttpAPIRequest - -response header: BFI-Number-Records: 34
[DEBUG] HttpAPIRequest - -response header: Connection: close
[DEBUG] HttpAPIRequest - -response header: Transfer-Encoding: chunked
[DEBUG] HttpAPIRequest - -response header: Content-Type: text/plain
[DEBUG] HttpAPIRequest - -response body:
[INFO] DreamAPIRequest - -BFI-Status: OK
[INFO] DreamAPIRequest - -BFI-Status-String:
[INFO] DreamAPIRequest - -BFI-Number-Records: 34
[INFO] FileUtility - -Writing string buffer to File:
email_response.datAppend Flag: false
Chris Morris
Sorry about the footer... I have no control over what the exchange
server appends to my messages on my behalf...
-----Original Message-----
From: Roland Weber [mailto:ossfwot@dubioso.net]
Sent: Thursday, September 27, 2007 9:33 AM
To: HttpClient User Discussion
Subject: Re: HTTP Response contains headers last
Morris, Chris wrote:
> I'm working with an API that returns the HTTP Response Headers after
the
> response body. This confuses the HTTPClient and PostMethod into
> thinking that there is no body.
We have code to handle footers in ChunkedInputStream. However,
this is the first time that I encounter footers in the wild,
so maybe that code is buggy. Could you please post a wire log,
including headers and content? Feel free to obfuscate any
sensitive information and cut the contents.
http://jakarta.apache.org/httpcomponents/httpclient-3.x/logging.html
> Is there a way for me to get direct
> access to the response input stream so that I can parse it out myself?
You can hack through the code of course. The socket's stream
is not accessible directly, because the ChunkedInputStream has
to parse the "chunked" encoding. Trailers are only allowed with
chunked encoding. If you have to hack through the code anyway,
you should rather fix what is broken than work around what is
already there.
> The information contained in this communication is
> confidential, and is intended only for the sole use of
> the recipient named above. [...]
Always funny to read these footers on mails sent to public
mailing lists...
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
The information contained in this communication is
confidential, and is intended only for the sole use of
the recipient named above. If the reader of this
message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have
received this communication in error, please re-send
this communication to the sender and delete the original
message or any copy of it from your computer system.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: HTTP Response contains headers last
Posted by Roland Weber <os...@dubioso.net>.
Morris, Chris wrote:
> I'm working with an API that returns the HTTP Response Headers after the
> response body. This confuses the HTTPClient and PostMethod into
> thinking that there is no body.
We have code to handle footers in ChunkedInputStream. However,
this is the first time that I encounter footers in the wild,
so maybe that code is buggy. Could you please post a wire log,
including headers and content? Feel free to obfuscate any
sensitive information and cut the contents.
http://jakarta.apache.org/httpcomponents/httpclient-3.x/logging.html
> Is there a way for me to get direct
> access to the response input stream so that I can parse it out myself?
You can hack through the code of course. The socket's stream
is not accessible directly, because the ChunkedInputStream has
to parse the "chunked" encoding. Trailers are only allowed with
chunked encoding. If you have to hack through the code anyway,
you should rather fix what is broken than work around what is
already there.
> The information contained in this communication is
> confidential, and is intended only for the sole use of
> the recipient named above. [...]
Always funny to read these footers on mails sent to public
mailing lists...
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org