Now to my problems (using version 2.0 rc2):
I'm dealing with a site that serves invalid Cookies in various kind of ways. In some cases the Cookie values contain "," characters, which really confuses the Header/Cookie parsers and eventually leads to IllegalArgumentExceptions thrown by the Cookie constructor:
java.lang.IllegalArgumentException: Cookie name may not be blank
at org.apache.commons.httpclient.Cookie.<init>(Cookie.java:142)
at org.apache.commons.httpclient.cookie.CookieSpecBase.parse(CookieSpecBase .java:192)
at org.apache.commons.httpclient.cookie.CookieSpecBase.parse(CookieSpecBase .java:256)
at org.apache.commons.httpclient.HttpMethodBase.processResponseHeaders(Http MethodBase.java:1826)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase .java:1939)
at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2631)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1085)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 74)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29)
at my.code.Test.getHttp(Test.java:114)
What bothers me, is that these IllegalArgumentExceptions are never caught in the HttpClient code, making it effectivily impossible to handle these responses.
My questions/suggestions:
1) There are lots of IllegalArgumentExceptions thrown in CookieSpecBase and Cookie. These should be either caught, or replaced with (or converted to) MalformedCookieExceptions, which are handled in HttpMethodBase.
2) Wouldn't it make sense to create an additional CookiePolicy.IGNORE_COOKIES that disables cookie parsing? This would be useful, if you either do not care about Cookies or if they are so messed up, that there is no hope parsing them.
3) Finally, wouldn't it be nice to have the possibility to plug-in your own custom Cookie parser, allowing more control with parsing/validating bad Cookies? Something like
HttpState.setCookiePolicy( CookiePolicy.CUSTOM, myCustomCookieSpec)
shouldn't be too difficult to implement.
Cheers,
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
