How to post to a URL with Checkbox ?
Hello, If the HTML form is like the following : form method=post action=/servlet/Show input type=checkbox name=cb input type=text name=n input type=submit value=Show /form How can Post to /servlet/Show with the values as following ? n=Eric and the CheckBox should be CHECKED Please help ??? Best regards, Eric == If you know what you are doing, it is not called RESEARCH! == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.javaTestMethodsExternalHost.javaTestWebappBasicAuth.java
Hi Oleg, this thread has gotten a bit out of hand now... I personally trust the HttpClient team to make the right decisions about the future of the code, and I even agree with the wording of the 2.1 release plan. Breaking 2.0 API compatibility where absolutely unavoidable is acceptable, as long as that sentence cannot interpreted as a free ticket to change the API all over the place. Now, what started this discussion was just me pointing out that you removed a technically non-deprecated method. Your response sounded a bit offensive, implying that we're doing something weird by using CVS HEAD of HttpClient (which is totally normal at Jakarta). And your comment about API compatibility sounded like you don't care very much about preserving compatibility. There is a *huge* difference between we should make all possible efforts to keep API compatibility (Michael) and we will no longer be able to provide API compatibility (Oleg). And the difference might not even be technical ;-) Cheers, -chris -- Christopher Lenz /=/ cmlenz at gmx.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to post to a URL with Checkbox ?
HttpClient client = new HttpClient(); HttpMethod method = new PostMethod(URL); NameValuePair pair = new NameValuePair[2]; pair[0] = new NameValuePair(cb, on); pair[1] = new NameValuePair(n, Eric); ((PostMethod) method).setRequestBody(parameters); client.executeMethod(method); byte[] responseBody = method.getResponseBody(); HTH, NOTE: You will have to add appropriate error/exception handling. Regards, Amit. -Original Message- From: Eric Chow [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 4:55 PM To: [EMAIL PROTECTED] Subject: How to post to a URL with Checkbox ? Hello, If the HTML form is like the following : form method=post action=/servlet/Show input type=checkbox name=cb input type=text name=n input type=submit value=Show /form How can Post to /servlet/Show with the values as following ? n=Eric and the CheckBox should be CHECKED Please help ??? Best regards, Eric == If you know what you are doing, it is not called RESEARCH! == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to post to a URL with Checkbox ?
HttpClient client = new HttpClient(); HttpMethod method = new PostMethod(URL); NameValuePair pair = new NameValuePair[2]; pair[0] = new NameValuePair(cb, on); pair[1] = new NameValuePair(n, Eric); ((PostMethod) method).setRequestBody(parameters); client.executeMethod(method); byte[] responseBody = method.getResponseBody(); HTH, NOTE: You will have to add appropriate error/exception handling. Regards, Amit. -Original Message- From: Eric Chow [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 4:55 PM To: [EMAIL PROTECTED] Subject: How to post to a URL with Checkbox ? Hello, If the HTML form is like the following : form method=post action=/servlet/Show input type=checkbox name=cb input type=text name=n input type=submit value=Show /form How can Post to /servlet/Show with the values as following ? n=Eric and the CheckBox should be CHECKED Please help ??? Best regards, Eric == If you know what you are doing, it is not called RESEARCH! == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to post to a URL with Checkbox ?
input type=checkbox name=cb value=CHECKED regards, Roland
RE: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java TestMethodsExternalHost.javaTestWebappBasicAuth.java
Christopher, this thread has gotten a bit out of hand now... As long as we manage behaving as mature people, I see no problem in talking things through offensive, implying that we're doing something weird by using CVS HEAD of HttpClient (which is totally normal at Jakarta). And your comment about API compatibility sounded like you don't care very much about preserving compatibility. I apologize if my response sounded harsh to you. Allow me to point out, though, the problems of maintaining 2.0 API compatibility have been discussed repeatedly on this mailing list before, and the decision has been taken BY THE HTTPCLIENT COMMUNITY AS EARLY AS FEBRUARY that maintaining 2.0 compatibility was not feasible due to limitations of the existing architecture. It was a very hard decision and it has not been taken lightly. I believe there was nothing that precluded you from taking part in that decision making process and influencing its outcome. But once the decision has been taken, I do find it a bit irresponsible, to come up with (what I see as) demands to change the course of HttpClient development that suits best your particular project. We have been very explicit about API compatibility issue MONTHS IN ADVANCE: there's a 2.0 branch which will provide you with FULL API compatibility, and you will have our full support migrating to 2.1 once is its APIs are frozen, but further development of HttpClient is not possible without limited API changes in the 2.1 branch. There is a *huge* difference between we should make all possible efforts to keep API compatibility (Michael) and we will no longer be able to provide API compatibility (Oleg). And the difference might not even be technical ;-) I have always been a bad guy of HttpClient community ;-) And will remain a bad guy as long people are not willing to listen to their counterparts' arguments Cheers Evil Comrade Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Array of values ???
Hello,
The following is a HTML form with a set of same name. How can use
HttpClient to post them ??
Best regards,
Eric
=
script language=JavaScript
C_ITEM_NO = 5;
C_BOOKING_HOUR_LIMIT = 3;
function check_input() {
i = 0;
fillCnt = 0;
loopCnt = C_ITEM_NO - 1;
isPrevItemEmptyFlag = false;
isItemValidFlag = false;
while (i = loopCnt) {
isItemEmptyFlag = check_item_empty(i);
if (isItemEmptyFlag == false) {
if (isPrevItemEmptyFlag == true) {
alert(Please fill in your booking items in sequential order.);
document.bform.wv_booking_date[i-1].focus();
return false;
}
isItemValidFlag = check_item(i);
if (isItemValidFlag == false) {
return false;
}
isItemDuplicated = check_item_duplication(i);
if (isItemDuplicated == true) {
return false;
}
isBookingHourOverLimit = check_item_hour_over_limit(i);
if (isBookingHourOverLimit == true) {
return false;
}
fillCnt++;
}
if (document.bform.chk_booking_light[i].checked) {
document.bform.wv_booking_light[i].value = Y;
} else {
document.bform.wv_booking_light[i].value = N;
}
if (document.bform.chk_booking_air[i].checked) {
document.bform.wv_booking_air[i].value = Y;
} else {
document.bform.wv_booking_air[i].value = N;
}
isPrevItemEmptyFlag = (isItemEmptyFlag == true)?true:false;
i++;
}
//alert(fillCnt: + fillCnt);
if (parseInt(fillCnt) == 0) {
alert(Please fill in at least one activity.);
document.bform.wv_booking_date[0].focus();
return false;
}
return true;
}
function FromTimeChange(i)
{
document.bform.wv_booking_time_to[i].options.selectedIndex =
document.bform.wv_booking_time_from[i].options.selectedIndex
return true;
}
function check_facility_existence (i) {
if (document.bform.wv_booking_place[i].options.selectedIndex == 0) {
document.bform.chk_booking_light[i].disabled=false;
document.bform.chk_booking_air[i].disabled=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'PAV') {
document.bform.chk_booking_light[i].disabled=true;
document.bform.chk_booking_light[i].checked=false;
document.bform.chk_booking_air[i].disabled=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'SQ1') {
document.bform.chk_booking_light[i].disabled=true;
document.bform.chk_booking_light[i].checked=false;
document.bform.chk_booking_air[i].disabled=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'SQ2') {
document.bform.chk_booking_light[i].disabled=true;
document.bform.chk_booking_light[i].checked=false;
document.bform.chk_booking_air[i].disabled=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'T1') {
document.bform.chk_booking_light[i].disabled=false;
document.bform.chk_booking_air[i].disabled=true;
document.bform.chk_booking_air[i].checked=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'T2') {
document.bform.chk_booking_light[i].disabled=false;
document.bform.chk_booking_air[i].disabled=true;
document.bform.chk_booking_air[i].checked=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'ZDR') {
document.bform.chk_booking_light[i].disabled=true;
document.bform.chk_booking_light[i].checked=false;
document.bform.chk_booking_air[i].disabled=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'ZS1') {
document.bform.chk_booking_light[i].disabled=true;
document.bform.chk_booking_light[i].checked=false;
document.bform.chk_booking_air[i].disabled=true;
document.bform.chk_booking_air[i].checked=false;
}
if (trim(document.bform.wv_booking_place[i].value) == 'ZS2') {
document.bform.chk_booking_light[i].disabled=true;
document.bform.chk_booking_light[i].checked=false;
document.bform.chk_booking_air[i].disabled=true;
document.bform.chk_booking_air[i].checked=false;
}
}
function check_item(i) {
if ( document.bform.wv_booking_date[i].options.selectedIndex == 0)
{
alert(The booking date is invalid);
document.bform.wv_booking_date[i].focus(); return false;
}
if ( document.bform.wv_booking_place[i].options.selectedIndex == 0)
{
alert(The booking place is empty);
document.bform.wv_booking_place[i].focus(); return false;
}
v_facilities = trim(document.bform.wv_booking_facilities[i].value);
if (trim(document.bform.wv_booking_place[i].value) == 'PAV') {
if (v_facilities.length == 0) {
alert(Please specify the facilities for using the complex
Pavilion, e.g. soccer, +
basketball, volleyball, badminton, table tennis or
handball,etc);
document.bform.wv_booking_facilities[i].focus(); return false;
}
}
Re: Array of values ???
Maybe there should be a guide for beginners (an FAQ?) as to how HttpClient can be used to mimic submitting form field values (via GET and/or POST) from a browser..? Might be particularly interesting for those wishing to use this approach to send multipart forms containing input type=file/ - Chris - Original Message - From: Eric Chow [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 07, 2003 11:47 AM Subject: Array of values ??? Hello, The following is a HTML form with a set of same name. How can use HttpClient to post them ?? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Array of values ???
The following is a HTML form with a set of same name. How can use HttpClient to post them ?? PostMethod.addParameter(...) allows the same parameter name to be used multiple times. Or you can try a comma-separated list of the values you want to send. regards, Roland
Re: [Proposal] exception handling revised
Oleg Kalnichevski wrote:
One of the major shortcomings of the existing architecture is unclear
and convoluted exception handling framework.
Here's the list of my personal gripes with it
- there is no clear-cut distinction between protocol exceptions (that
are in most cases fatal) and transport exception (that are in most cases
recoverable). As a result possible recovery strategy is not clear (at
least to me)
Quite so. I would be wary about trying to recover from an exception
with the current configuration. As a user currently, the only safe
assumtion is that all exceptions are fatal.
- Why on earth does HttpException have to extend URIException? That's
just lunacy on a massive scale.
This one has always confused me as well. It probably made some sense at
the time.
- HttpClient#excecuteMethod HttpMethodBase#execute declare but never
throw IOException
I think this is just to get around throwing a URIException explicitly...
maybe:)
I personally see two ways of fixing things
1) Back to the roots
-
This approach is basically about going back to a very simple, but clear
framework that existed before but got messed up on the way toward
beta-1.
org.apache.commons.httpclient.HttpException (Root protocol exception)
|
+-- org.apache.commons.httpclient.cookie.MalformedCookieException
|
+-- org.apache.commons.httpclient.auth.AuthenticationException
|
+-- ...
java.io.IOException (Root transport exception;
| all i/o exceptions considered recoverable. Period)
|
+-- java.io.InterruptedIOException (timeout)
|
+-- ...
Pros:
- simplicity
- no need to 'warp' or 'chain' exceptions. No need for Commons-lang
Cons:
- Some i/o exceptions MIGHT be unrecoverable, but at the moment I can't
think of a single one
I think the one case is when an IO exception occurs after content has
been posted. This is what the MethodRetryHandler was created to handle.
- It may not be apparent to everyone that a request that has caused an
IOException can be retired
2) Go elaborate
-
org.apache.commons.lang.exception.NestableException (or equivalent)
|
+-- org.apache.commons.httpclient.HttpException (Root exception)
|
+-- ...httpclient.HttpProtocolException (Root protocol exception)
| |
| +-- ...httpclient.cookie.MalformedCookieException
| |
| +-- ...httpclient.auth.AuthenticationException
| |
| +-- ...
|
+-- ...httpclient.HttpTransportException
| (should 'wrap' java.io.IOException)
|
+-- ...httpclient.RecoverableHttpException
| |
| +-- ...httpclient.TimeoutHttpException
| |
| +-- ...httpclient.ConnectTimeoutHttpException
| |
| +-- ...httpclient.IOTimeoutHttpException
|
+-- ...httpclient.InterruptedHttpException
Pros:
- flexibility
- clarity
Cons:
- complexity
- most likely requires an external dependency
In my opinion we MUST get exception handling right before we do anything
else. Exception handling is a foundation of any flexible architecture.
I personally can live with either of these two approaches. If you see
other alternatives, please share your ideas
Here's a third option, one that would keep API compatability I think:
java.io.IOException
|
+-- org.apache.commons.httpclient.HttpException (Root protocol
| |exception, also supports nestable exceptions via
| |Lang or our own custom method)
| |
| +-- org.apache.commons.httpclient.cookie.MalformedCookieException
| |
| +-- org.apache.commons.httpclient.auth.AuthenticationException
| |
| +-- ...
|
|
+-- java.io.InterruptedIOException (timeout)
|
+-- ...
This would allow compatibility with people who are currently doing the
following:
try {
client.executeMethod(someMethod);
} catch (IOException e) {
// some stuff
}
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Occassional long download times
Michael, You might try turning on the wire and/or trace logging (which sounds like it might generate a lot of data), but it would also tell you exactly where the delay occurs. Knowing where the culprit occurs would provide additional detail that might clearly identify whether the problem lies with HttpClient or the network. -Eric. Michael Mattox wrote: I'm experiencing something weird and I just want to see if anyone else has experienced it, and if it may be something I'm doing. Basically my application is monitoring 700+ websites every 5 minutes and timing the time it takes to connect and download. The main goal is to verify the site is working, so I don't need exact precision on the times. Here's some of my code to time the download: method = new GetMethod(uri.toString()); method.setFollowRedirects(true); method.setHttp11(false); DefaultMethodRetryHandler retry = new DefaultMethodRetryHandler(); retry.setRequestSentRetryEnabled(true); retry.setRetryCount(3); method.setMethodRetryHandler(retry); start = System.currentTimeMillis(); method.execute(state, connection); msi.setDuration(System.currentTimeMillis() - start); What I see is that normally I get download times 150ms and then occassionally (4-5 times a day) I see a download time of 3000ms. It happens to the majority of the websites, so I do not believe it's a particular site. So it must be either my application, or the network. My application uses a thread pool and always has multiple threads running (typically 8 at a time on a 4 CPU machine that's also running tomcat and Postgres), and I've seen that at exactly the same time a website has a 3000ms download time several others have normal 150ms times. So this seems to rule out the network. I set my threads to be all MAX_PRIORITY to minimize the interruptions. Are there any other explanations? Any ideas what I can do about it? My current thought is to put in some code to say if the download time is more than 10x the previous time then repeat the download to make sure. This way our customers wouldn't see the huge spike in the numbers, but at the same time if that spike really should be there I don't want to cover it up. Thanks, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HTTPClient exception
Hi all, I finally made the most basic SSL code run in my computer. Now I am trying to send Post requests with the HttpClient class. I get the following exception when I do the Execute method: java.net.SocketException: Socket closed at java.net.PlainSocketImpl.socketGetOption(Native Method) at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198) at java.net.Socket.getSendBufferSize(Socket.java:526) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70 3) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 25) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 00) at com.SSLPayment.sendPayment(SSLPayment.java:104) at com.SSLPayment.main(SSLPayment.java:143) My code is pretty straight forward, I create my PostMethod and add all the parameters I need to send (just 20 pairs of values) and after that execute this code: System.setProperty(java.protocol.handler.pkgs,com.ibm.net.ssl.interna l.www.protocol); java.security.Security.addProvider(new com.ibm.jsse.JSSEProvider()); status = hc.executeMethod( pm ); Does any body have an Idea why I am getting this error and can give me a hand to solve it. Thanks, Claudio. -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 9:57 PM To: Commons HttpClient Project Subject: Re: WSAD HTTPClient question Sorry Claudio, I'm not sure. This appears to be a configuration problem with WebSphere. I would suggest looking at IBM's support site or WebSphere newsgroups for more information. If you have a HttpClient specific question we will probably be of more help. Mike On Wednesday, July 2, 2003, at 11:57 AM, Claudio Santana wrote: Thanks to all that answered my help request, I am trying to run with IBM's WSAD 4.0.3, It comes with JDK 1.3. I am not trying to use specifically any special implementation of JCE or JSSE, it can be IBM's or SUN's. As you explain in your email it comes with IBM's implementation of JCE and JSSE. I already added that System Property java.protocol.handler.pkgs=com.ibm.net.ssl.internal.www.protocol in the environment in my WebSphere Test Environment but it makes no difference. Any other idea? Claudio. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 7:49 AM To: Commons HttpClient Project Subject: Re: WSAD HTTPClient question Laura is right, WSAD comes with the IBMJCE and IBMJSSE, which is only a problem if you absolutely require Sun's JSSE, or are using a signed third party JCE provider. If you do not require either of these, then all you need to do is make sure the java.protocol.handler.pkgs system property is pointing at: com.ibm.net.ssl.internal.www.protocol. And if you have been specifying a specific provider, stop doing that. If you do require Sun, then things get a little tricky. You will need to remove the following jars from your server's vm... another point - WSAD uses at least two vm's... the one that matters when debugging/running is the server vm... if I remember correctly it is under plugins.server.jdk (something like that). Ok, the jars: ibmjcefw.jar ibmjceprovider.jar ibmjsse.jar The above jars need to be replaced with the Sun JCE and JSSE jars (all of the jars from both packages). Then, you need to modify the java.security file, removing all of the IBM JCE/JSSE related provider lines, and replacing them with the Sun JCE/JSSE provider lines provided in the installation documents of both of the JCE and JSSE packages. Hope this helps. - Matt Laura Werner [EMAIL PROTECTED] 07/01/2003 05:57 PM Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: WSAD HTTPClient question Hi Claudio, Does any one know any special consideration I have to know in order to make this work under WSAD 4.03? If WSAD uses an IBM version of the JDK, which I think it does, you probably need to get the corresponding IBM version of JSSE. We once ran into a problem trying to use the Sun JSSE jars with an IBM JDK (1.3, if I remember right). -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378
Transfer-Encoding: identity not supported + possible patch
--- Additional Comments From [EMAIL PROTECTED] 2003-07-07 19:30 ---
A good catch, but I don't think the suggested patch is quite right, as it
doesn't compute the content length if the transferEncodingHeader is specified as
identity.
I think rearranging the two cases, something like this:
if (transferEncoding == null ||
identity.equalsIgnoreCase(transferEncoding.getValue() )) {
... do what is currently the second case
}
else if (chunked.equalsIgnoreCase(transferEncodingHeader.getValue() ) {
... do what is currently in the first case
}
else {
LOG.warn(Unexpected transfer encoding);
}
might work better. Since I don't have the indicated servers handy, perhaps the
submitter can try the suggested rearrangement?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 20:03 --- Created an attachment (id=7128) Patch (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 20:15 --- Hi Oleg, I just looked at the patch and was wondering if you should only warn if you're in Strict mode? Brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 20:22 --- Brent, That surely can be done. (I still think it is a pretty serious compliance problem on the part of Privoxy, and they should rather be warned, but I can live with a warning in strict mode only) Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 20:25 --- Created an attachment (id=7133) Patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 20:45 --- Brent, I don't suppose you could provide a wire log? It might help clarify. Oleg, I have no idea whether my analysis is correct or not. I only noticed this issue due to my almost pathological interest in making sure streams are properly wrapped. The RFC apparently got it wrong on this point. From section 3.6: The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: chunked (section 3.6.1), identity (section 3.6.2), gzip (section 3.5), compress (section 3.5), and deflate (section 3.5). Except that there is no section 3.6.2. I found these two links: http://lists.w3.org/Archives/Public/ietf-http-wg-old/2001SepDec/0018.html http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1998q3/0135.html Which seem to suggest that leaving identity in was a mistake. Maybe you knew all this, I certainly didn't. In any case, your assertion that only chunked is valid appears to be wrong, in that gzip, compress, and deflate are possible values too. Anyway, I think it is still necessary to be able to determine the content-length, so I think my original suggestion might be appropriate, if we support the identity transfer encoding at all. I've not had a chance to look at the patches you've supplied, just mining for information so far. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-07 21:29 --- Eric, I do not know it for sure either. I am just trying to make some (more or less) informed guesses. One thing for sure the RFC is terribly contradictory on this issue. 3.6 Transfer Codings ... Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include chunked, unless the message is terminated by closing the connection. When the chunked transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The chunked transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4). ... so, what I can gather from the above paragraph is that chunk encoding must be used anyway to ensure that the content length could be determined, no matter what additional encodings are appled. There's one thing I am pretty sure about that content length transfer encoding directives are mutually exclusive. 4.4 Message Length ... 3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. ... Anyways, what that all means to me that if (chunked.equalsIgnoreCase(transferEncodingHeader.getValue())) is really not good enough. The code needs to be made more robust when dealing with composite transfer encodings Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTPClient exception
I ran the basic connection program listed at the end of this email. I
can do a GET to Verisign website using SSL and direct socket connections
which means I no longer have the configuration problem. Some interesting
condition is that if I don't add the provider dynamically I get an error
of missing SSL Socket implementation.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;
public class Test {
public static final String TARGET_HTTPS_SERVER =
www.verisign.com;
public static final intTARGET_HTTPS_PORT = 443;
public static void main(String[] args) throws Exception {
System.setProperty(java.protocol.handler.pkgs,
com.ibm.net.ssl.internal.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);
try {
Writer out = new OutputStreamWriter(
socket.getOutputStream(), ISO-8859-1);
out.write(GET / HTTP/1.1\r\n);
out.write(Host: + TARGET_HTTPS_SERVER + : +
TARGET_HTTPS_PORT + \r\n);
out.write(Agent: SSL-TEST\r\n);
out.write(\r\n);
out.flush();
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream(),
ISO-8859-1));
String line = null;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:43 PM
To: Commons HttpClient Project
Subject: Re: HTTPClient exception
Claudio,
It's hard to tell what is going on there. Somehow I still suspect that
SSL support is mis-configured and the target server drops the connection
in the middle of the session.
Have you tried testing your SSL setup with the little trick described in
'Troubleshooting' section of the SSL guide?
http://jakarta.apache.org/commons/httpclient/sslguide.html
If the trick does not help to pinpoint the problem, please post the code
you are trying to execute
Cheers
Evil Comrade Oleg
On Mon, 2003-07-07 at 21:14, Claudio Santana wrote:
Hi all,
I finally made the most basic SSL code run in my computer. Now I
am
trying to send Post requests with the HttpClient class. I get the
following exception when I do the Execute method:
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198)
at java.net.Socket.getSendBufferSize(Socket.java:526)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70
3)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
25)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
00)
at com.SSLPayment.sendPayment(SSLPayment.java:104)
at com.SSLPayment.main(SSLPayment.java:143)
My code is pretty straight forward, I create my PostMethod and add all
the parameters I need to send (just 20 pairs of values) and after that
execute this code:
System.setProperty(java.protocol.handler.pkgs,com.ibm.net.ssl.interna
l.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
status = hc.executeMethod( pm );
Does any body have an Idea why I am getting this error and can give me
a
hand to solve it.
Thanks,
Claudio.
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:57 PM
To: Commons HttpClient Project
Subject: Re: WSAD HTTPClient question
Sorry Claudio, I'm not sure. This appears to be a configuration
problem with WebSphere. I would suggest looking at IBM's support site
or WebSphere newsgroups for more information. If you have a
HttpClient
specific question we will probably be of more help.
Mike
On Wednesday, July 2, 2003, at 11:57 AM, Claudio Santana wrote:
Thanks to all that answered my help request, I am trying to run
with IBM's WSAD 4.0.3, It comes with JDK 1.3. I am not trying to use
specifically any special implementation of JCE or JSSE, it can be
IBM's
or SUN's. As you explain in your email it comes with IBM's
implementation of JCE and JSSE. I already added that System Property
java.protocol.handler.pkgs=com.ibm.net.ssl.internal.www.protocol in
the
environment in my WebSphere Test Environment but it makes no
difference.
Any other idea?
Claudio.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003
RE: HTTPClient exception
Claudio, does the same code work with your target server?
Oleg
On Mon, 2003-07-07 at 23:49, Claudio Santana wrote:
I ran the basic connection program listed at the end of this email. I
can do a GET to Verisign website using SSL and direct socket connections
which means I no longer have the configuration problem. Some interesting
condition is that if I don't add the provider dynamically I get an error
of missing SSL Socket implementation.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;
public class Test {
public static final String TARGET_HTTPS_SERVER =
www.verisign.com;
public static final intTARGET_HTTPS_PORT = 443;
public static void main(String[] args) throws Exception {
System.setProperty(java.protocol.handler.pkgs,
com.ibm.net.ssl.internal.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);
try {
Writer out = new OutputStreamWriter(
socket.getOutputStream(), ISO-8859-1);
out.write(GET / HTTP/1.1\r\n);
out.write(Host: + TARGET_HTTPS_SERVER + : +
TARGET_HTTPS_PORT + \r\n);
out.write(Agent: SSL-TEST\r\n);
out.write(\r\n);
out.flush();
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream(),
ISO-8859-1));
String line = null;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:43 PM
To: Commons HttpClient Project
Subject: Re: HTTPClient exception
Claudio,
It's hard to tell what is going on there. Somehow I still suspect that
SSL support is mis-configured and the target server drops the connection
in the middle of the session.
Have you tried testing your SSL setup with the little trick described in
'Troubleshooting' section of the SSL guide?
http://jakarta.apache.org/commons/httpclient/sslguide.html
If the trick does not help to pinpoint the problem, please post the code
you are trying to execute
Cheers
Evil Comrade Oleg
On Mon, 2003-07-07 at 21:14, Claudio Santana wrote:
Hi all,
I finally made the most basic SSL code run in my computer. Now I
am
trying to send Post requests with the HttpClient class. I get the
following exception when I do the Execute method:
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198)
at java.net.Socket.getSendBufferSize(Socket.java:526)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70
3)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
25)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
00)
at com.SSLPayment.sendPayment(SSLPayment.java:104)
at com.SSLPayment.main(SSLPayment.java:143)
My code is pretty straight forward, I create my PostMethod and add all
the parameters I need to send (just 20 pairs of values) and after that
execute this code:
System.setProperty(java.protocol.handler.pkgs,com.ibm.net.ssl.interna
l.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
status = hc.executeMethod( pm );
Does any body have an Idea why I am getting this error and can give me
a
hand to solve it.
Thanks,
Claudio.
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:57 PM
To: Commons HttpClient Project
Subject: Re: WSAD HTTPClient question
Sorry Claudio, I'm not sure. This appears to be a configuration
problem with WebSphere. I would suggest looking at IBM's support site
or WebSphere newsgroups for more information. If you have a
HttpClient
specific question we will probably be of more help.
Mike
On Wednesday, July 2, 2003, at 11:57 AM, Claudio Santana wrote:
Thanks to all that answered my help request, I am trying to run
with IBM's WSAD 4.0.3, It comes with JDK 1.3. I am not trying to use
specifically any special implementation of JCE or JSSE, it can be
IBM's
or SUN's. As you explain in your email it comes with IBM's
implementation of JCE and JSSE. I already added that System Property
RE: HTTPClient exception
I didn't check that before... now I just ran it against my target
server... www.autorize.net/gateway/transact.dll
I receive the following exception:
javax.net.ssl.SSLHandshakeException: unknown CA
at com.ibm.jsse.JSSESocket.install(Unknown Source)
at com.ibm.jsse.JSSEOutputStream.install(Unknown Source)
at com.ibm.jsse.JSSEOutputStream.write(Unknown Source)
at
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:236)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:250)
at com.Test.main(Test.java:32)
Exception in thread main
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:55 PM
To: Commons HttpClient Project
Subject: RE: HTTPClient exception
Claudio, does the same code work with your target server?
Oleg
On Mon, 2003-07-07 at 23:49, Claudio Santana wrote:
I ran the basic connection program listed at the end of this email. I
can do a GET to Verisign website using SSL and direct socket
connections
which means I no longer have the configuration problem. Some
interesting
condition is that if I don't add the provider dynamically I get an
error
of missing SSL Socket implementation.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;
public class Test {
public static final String TARGET_HTTPS_SERVER =
www.verisign.com;
public static final intTARGET_HTTPS_PORT = 443;
public static void main(String[] args) throws Exception {
System.setProperty(java.protocol.handler.pkgs,
com.ibm.net.ssl.internal.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);
try {
Writer out = new OutputStreamWriter(
socket.getOutputStream(), ISO-8859-1);
out.write(GET / HTTP/1.1\r\n);
out.write(Host: + TARGET_HTTPS_SERVER + : +
TARGET_HTTPS_PORT + \r\n);
out.write(Agent: SSL-TEST\r\n);
out.write(\r\n);
out.flush();
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream(),
ISO-8859-1));
String line = null;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:43 PM
To: Commons HttpClient Project
Subject: Re: HTTPClient exception
Claudio,
It's hard to tell what is going on there. Somehow I still suspect that
SSL support is mis-configured and the target server drops the
connection
in the middle of the session.
Have you tried testing your SSL setup with the little trick described
in
'Troubleshooting' section of the SSL guide?
http://jakarta.apache.org/commons/httpclient/sslguide.html
If the trick does not help to pinpoint the problem, please post the
code
you are trying to execute
Cheers
Evil Comrade Oleg
On Mon, 2003-07-07 at 21:14, Claudio Santana wrote:
Hi all,
I finally made the most basic SSL code run in my computer. Now
I
am
trying to send Post requests with the HttpClient class. I get the
following exception when I do the Execute method:
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198)
at java.net.Socket.getSendBufferSize(Socket.java:526)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70
3)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
25)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
00)
at com.SSLPayment.sendPayment(SSLPayment.java:104)
at com.SSLPayment.main(SSLPayment.java:143)
My code is pretty straight forward, I create my PostMethod and add
all
the parameters I need to send (just 20 pairs of values) and after
that
execute this code:
System.setProperty(java.protocol.handler.pkgs,com.ibm.net.ssl.interna
l.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
status = hc.executeMethod( pm );
Does any body have an Idea why I am getting this error and can give
me
a
hand to solve it.
Thanks,
Claudio.
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 9:57 PM
To: Commons HttpClient Project
Subject: Re: WSAD
RE: HTTPClient exception
Well, that is it. Have a look at EasyX509TrustManager.java
EasySSLProtocolSocketFactory.java classes. They should help you to get a
handle on the situation
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/
I have got to go to bed. Evil comrades do need some sleep too
Evil Comrade Oleg
On Mon, 2003-07-07 at 23:59, Claudio Santana wrote:
I didn't check that before... now I just ran it against my target
server... www.autorize.net/gateway/transact.dll
I receive the following exception:
javax.net.ssl.SSLHandshakeException: unknown CA
at com.ibm.jsse.JSSESocket.install(Unknown Source)
at com.ibm.jsse.JSSEOutputStream.install(Unknown Source)
at com.ibm.jsse.JSSEOutputStream.write(Unknown Source)
at
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:236)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:250)
at com.Test.main(Test.java:32)
Exception in thread main
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:55 PM
To: Commons HttpClient Project
Subject: RE: HTTPClient exception
Claudio, does the same code work with your target server?
Oleg
On Mon, 2003-07-07 at 23:49, Claudio Santana wrote:
I ran the basic connection program listed at the end of this email. I
can do a GET to Verisign website using SSL and direct socket
connections
which means I no longer have the configuration problem. Some
interesting
condition is that if I don't add the provider dynamically I get an
error
of missing SSL Socket implementation.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;
public class Test {
public static final String TARGET_HTTPS_SERVER =
www.verisign.com;
public static final intTARGET_HTTPS_PORT = 443;
public static void main(String[] args) throws Exception {
System.setProperty(java.protocol.handler.pkgs,
com.ibm.net.ssl.internal.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);
try {
Writer out = new OutputStreamWriter(
socket.getOutputStream(), ISO-8859-1);
out.write(GET / HTTP/1.1\r\n);
out.write(Host: + TARGET_HTTPS_SERVER + : +
TARGET_HTTPS_PORT + \r\n);
out.write(Agent: SSL-TEST\r\n);
out.write(\r\n);
out.flush();
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream(),
ISO-8859-1));
String line = null;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:43 PM
To: Commons HttpClient Project
Subject: Re: HTTPClient exception
Claudio,
It's hard to tell what is going on there. Somehow I still suspect that
SSL support is mis-configured and the target server drops the
connection
in the middle of the session.
Have you tried testing your SSL setup with the little trick described
in
'Troubleshooting' section of the SSL guide?
http://jakarta.apache.org/commons/httpclient/sslguide.html
If the trick does not help to pinpoint the problem, please post the
code
you are trying to execute
Cheers
Evil Comrade Oleg
On Mon, 2003-07-07 at 21:14, Claudio Santana wrote:
Hi all,
I finally made the most basic SSL code run in my computer. Now
I
am
trying to send Post requests with the HttpClient class. I get the
following exception when I do the Execute method:
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198)
at java.net.Socket.getSendBufferSize(Socket.java:526)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70
3)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
25)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
00)
at com.SSLPayment.sendPayment(SSLPayment.java:104)
at com.SSLPayment.main(SSLPayment.java:143)
My code is pretty straight forward, I create my PostMethod and add
all
the parameters I need to send (just 20 pairs of values) and after
that
execute this code:
RE: HTTPClient exception
Thanks! I hope this helps to solve my situation! Have a nice sleep!
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:09 PM
To: Commons HttpClient Project
Subject: RE: HTTPClient exception
Well, that is it. Have a look at EasyX509TrustManager.java
EasySSLProtocolSocketFactory.java classes. They should help you to get a
handle on the situation
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib
/org/apache/commons/httpclient/contrib/ssl/
I have got to go to bed. Evil comrades do need some sleep too
Evil Comrade Oleg
On Mon, 2003-07-07 at 23:59, Claudio Santana wrote:
I didn't check that before... now I just ran it against my target
server... www.autorize.net/gateway/transact.dll
I receive the following exception:
javax.net.ssl.SSLHandshakeException: unknown CA
at com.ibm.jsse.JSSESocket.install(Unknown Source)
at com.ibm.jsse.JSSEOutputStream.install(Unknown Source)
at com.ibm.jsse.JSSEOutputStream.write(Unknown Source)
at
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:236)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:250)
at com.Test.main(Test.java:32)
Exception in thread main
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:55 PM
To: Commons HttpClient Project
Subject: RE: HTTPClient exception
Claudio, does the same code work with your target server?
Oleg
On Mon, 2003-07-07 at 23:49, Claudio Santana wrote:
I ran the basic connection program listed at the end of this email.
I
can do a GET to Verisign website using SSL and direct socket
connections
which means I no longer have the configuration problem. Some
interesting
condition is that if I don't add the provider dynamically I get an
error
of missing SSL Socket implementation.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import javax.net.ssl.SSLSocketFactory;
public class Test {
public static final String TARGET_HTTPS_SERVER =
www.verisign.com;
public static final intTARGET_HTTPS_PORT = 443;
public static void main(String[] args) throws Exception {
System.setProperty(java.protocol.handler.pkgs,
com.ibm.net.ssl.internal.www.protocol);
java.security.Security.addProvider(new
com.ibm.jsse.JSSEProvider());
Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);
try {
Writer out = new OutputStreamWriter(
socket.getOutputStream(), ISO-8859-1);
out.write(GET / HTTP/1.1\r\n);
out.write(Host: + TARGET_HTTPS_SERVER + : +
TARGET_HTTPS_PORT + \r\n);
out.write(Agent: SSL-TEST\r\n);
out.write(\r\n);
out.flush();
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream(),
ISO-8859-1));
String line = null;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
} finally {
socket.close();
}
}
}
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:43 PM
To: Commons HttpClient Project
Subject: Re: HTTPClient exception
Claudio,
It's hard to tell what is going on there. Somehow I still suspect
that
SSL support is mis-configured and the target server drops the
connection
in the middle of the session.
Have you tried testing your SSL setup with the little trick
described
in
'Troubleshooting' section of the SSL guide?
http://jakarta.apache.org/commons/httpclient/sslguide.html
If the trick does not help to pinpoint the problem, please post the
code
you are trying to execute
Cheers
Evil Comrade Oleg
On Mon, 2003-07-07 at 21:14, Claudio Santana wrote:
Hi all,
I finally made the most basic SSL code run in my computer.
Now
I
am
trying to send Post requests with the HttpClient class. I get the
following exception when I do the Execute method:
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:198)
at java.net.Socket.getSendBufferSize(Socket.java:526)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70
3)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
25)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
00)
at com.SSLPayment.sendPayment(SSLPayment.java:104)
Re: [Proposal] exception handling revised
On Monday, July 7, 2003, at 10:36 AM, Kalnichevski, Oleg wrote: I would not be me, though, if I had not pointed out that HttpException derived from IOException still conceptually sucks. Protocol exceptions logically ARE NOT i/o exceptions in my opinion, no matter how many long drinks you take. I agree this is not the prettiest solution, but such is life. I am glad we have you here to play devil's advocate. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-08 00:45 --- Created an attachment (id=7143) Patch (try 3) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378 Transfer-Encoding: identity not supported + possible patch --- Additional Comments From [EMAIL PROTECTED] 2003-07-08 00:46 --- I think this patch should take care of composite Transfer Encoding headers. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] exception handling revised
As an addendum to my previous email, it would also be possible to use
Oleg's #2 option and just change HttpException to extend IOException.
This would also allow us to keep API compatability. If this was done we
could remove the throws IOException from HttpClient.executeMethod().
Mike
Michael Becke wrote:
Oleg Kalnichevski wrote:
One of the major shortcomings of the existing architecture is unclear
and convoluted exception handling framework.
Here's the list of my personal gripes with it
- there is no clear-cut distinction between protocol exceptions (that
are in most cases fatal) and transport exception (that are in most cases
recoverable). As a result possible recovery strategy is not clear (at
least to me)
Quite so. I would be wary about trying to recover from an exception
with the current configuration. As a user currently, the only safe
assumtion is that all exceptions are fatal.
- Why on earth does HttpException have to extend URIException? That's
just lunacy on a massive scale.
This one has always confused me as well. It probably made some sense at
the time.
- HttpClient#excecuteMethod HttpMethodBase#execute declare but never
throw IOException
I think this is just to get around throwing a URIException explicitly...
maybe:)
I personally see two ways of fixing things
1) Back to the roots -
This approach is basically about going back to a very simple, but clear
framework that existed before but got messed up on the way toward
beta-1.
org.apache.commons.httpclient.HttpException (Root protocol exception)
|
+-- org.apache.commons.httpclient.cookie.MalformedCookieException
|
+-- org.apache.commons.httpclient.auth.AuthenticationException
|
+-- ...
java.io.IOException (Root transport exception; |
all i/o exceptions considered recoverable. Period)
|
+-- java.io.InterruptedIOException (timeout)
|
+-- ...
Pros:
- simplicity
- no need to 'warp' or 'chain' exceptions. No need for Commons-lang
Cons:
- Some i/o exceptions MIGHT be unrecoverable, but at the moment I can't
think of a single one
I think the one case is when an IO exception occurs after content has
been posted. This is what the MethodRetryHandler was created to handle.
- It may not be apparent to everyone that a request that has caused an
IOException can be retired
2) Go elaborate
-
org.apache.commons.lang.exception.NestableException (or equivalent)
|
+-- org.apache.commons.httpclient.HttpException (Root exception)
|
+-- ...httpclient.HttpProtocolException (Root protocol exception)
| |
| +-- ...httpclient.cookie.MalformedCookieException
| |
| +-- ...httpclient.auth.AuthenticationException
| |
| +-- ...
|
+-- ...httpclient.HttpTransportException| (should 'wrap'
java.io.IOException)
|
+-- ...httpclient.RecoverableHttpException
| |
| +-- ...httpclient.TimeoutHttpException
| |
| +-- ...httpclient.ConnectTimeoutHttpException
| |
| +-- ...httpclient.IOTimeoutHttpException
|
+-- ...httpclient.InterruptedHttpException
Pros:
- flexibility
- clarity
Cons:
- complexity
- most likely requires an external dependency
In my opinion we MUST get exception handling right before we do anything
else. Exception handling is a foundation of any flexible architecture.
I personally can live with either of these two approaches. If you see
other alternatives, please share your ideas
Here's a third option, one that would keep API compatability I think:
java.io.IOException
|
+-- org.apache.commons.httpclient.HttpException (Root protocol
| |exception, also supports nestable exceptions via
| |Lang or our own custom method)
| |
| +-- org.apache.commons.httpclient.cookie.MalformedCookieException
| |
| +-- org.apache.commons.httpclient.auth.AuthenticationException
| |
| +-- ...
|
|
+-- java.io.InterruptedIOException (timeout)
|
+-- ...
This would allow compatibility with people who are currently doing the
following:
try {
client.executeMethod(someMethod);
} catch (IOException e) {
// some stuff
}
Mike
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] exception handling revised
Oleg, Thanks for digging into this. Oleg Kalnichevski wrote: One of the major shortcomings of the existing architecture is unclear and convoluted exception handling framework. Here's the list of my personal gripes with it - there is no clear-cut distinction between protocol exceptions (that are in most cases fatal) and transport exception (that are in most cases recoverable). As a result possible recovery strategy is not clear (at least to me) - Why on earth does HttpException have to extend URIException? That's just lunacy on a massive scale. - HttpClient#excecuteMethod HttpMethodBase#execute declare but never throw IOException I'd add my gripe that I simply don't know what exceptions to expect to get! It occurs to me that it might be a good idea to enumerate the possible failure points for which we want to establish a contract and stick to those expectations. The scenarios I can think of, as suggested by some of our existing exception classes, and what I can recall of cases I've worried about. * Authentication failure - AuthenticationException * Authentication protocol failure - MalformedChallengeException * Bad URI - URIException * Cookie protocol failure - MalformedCookieException * Date protocol failure - DateException * Server not responding to initial attempt at communication - IOException? * Server not found (DNS lookup failure?) - IOException? * protocol failure - currently triggered by a failure to find HTTP/1.0 or HTTP/1.1 status response line - call this HttpProtocolFailure? * Just about any communications/IO failure during send - perhaps we call this HttpSendFailure - but wrap underlying IOException? * Just about any communications/IO failure during response - perhaps we call this HttpReceiveFailure - but wrap underlying IOException? * Too many redirects - perhaps HttpExcessiveRedirectException? There are some exceptions that currently occur internally that shouldn't be exposed to clients, such as attempts to write to a recycled connection that can fail since the connection is stale. Those failures clearly should generate retries with a fresh connection as we do now, and are really an artifact of how Java sockets work, not something that clients of HttpClient care about. With the scenarioes above, I only see two exceptions that might possible need to wrap other exceptions, so I lean towards the simpler approach that Oleg outlined. -Eric. I personally see two ways of fixing things 1) Back to the roots - This approach is basically about going back to a very simple, but clear framework that existed before but got messed up on the way toward beta-1. org.apache.commons.httpclient.HttpException (Root protocol exception) | +-- org.apache.commons.httpclient.cookie.MalformedCookieException | +-- org.apache.commons.httpclient.auth.AuthenticationException | +-- ... java.io.IOException (Root transport exception; | all i/o exceptions considered recoverable. Period) | +-- java.io.InterruptedIOException (timeout) | +-- ... Pros: - simplicity - no need to 'warp' or 'chain' exceptions. No need for Commons-lang Cons: - Some i/o exceptions MIGHT be unrecoverable, but at the moment I can't think of a single one - It may not be apparent to everyone that a request that has caused an IOException can be retired 2) Go elaborate - org.apache.commons.lang.exception.NestableException (or equivalent) | +-- org.apache.commons.httpclient.HttpException (Root exception) | +-- ...httpclient.HttpProtocolException (Root protocol exception) | | | +-- ...httpclient.cookie.MalformedCookieException | | | +-- ...httpclient.auth.AuthenticationException | | | +-- ... | +-- ...httpclient.HttpTransportException | (should 'wrap' java.io.IOException) | +-- ...httpclient.RecoverableHttpException | | | +-- ...httpclient.TimeoutHttpException | | | +-- ...httpclient.ConnectTimeoutHttpException | | | +-- ...httpclient.IOTimeoutHttpException | +-- ...httpclient.InterruptedHttpException Pros: - flexibility - clarity Cons: - complexity - most likely requires an external dependency In my opinion we MUST get exception handling right before we do anything else. Exception handling is a foundation of any flexible architecture. I personally can live with either of these two approaches. If you see other alternatives, please share your ideas Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
