Re: NameValuePair.equals
Ortwin Glück wrote: Why is it required that equals returns false if the classes do not match exactly? I thinks this is a weird behaviour for an equals method and should clearly be changed. It's weird behavior, but you have to be careful when changing it to instanceof. If an equals method tries to get too clever and suports equality with other types, you can end up with cases where equals is not symmetric, e.g. a.equals(b)==true but b.equals(a)==false. The usual if (other instanceof ThisClass) is usually safe, though. There's a good discussion of this in Effective Java by Josh Bloch. I think this book is a must-read for anyone doing API or class library development in Java. BTW, sorry I've been fairly scarce lately. I started a new job two weeks ago and I'm spending lots of time trying to get up to speed and figure out the environment here. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: strange behavior of 2.0-rc1
Leo Galambos wrote: I am using httpclient (HC) in a webcrawler. After 6 hours of run, HC stops working and I think, it is locked by some lock of a critical section in HC. The problematic code, I use, is here: http://www.egothor.org/temp/Network.java Are you running on Windows by any chance? It has a feature where the OS waits a very long time before deciding that half-closed sockets are really dead, so you can end up with lots of sockets in TIME_WAIT or CLOSE_WAIT states. There's a registry setting you can change to adjust the timeout down to a more reasonable value. This doesn't sound exactly like what you're seeing, but I thought I'd throw it out there... -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sample code link does not work
A few weeks ago I took a first stab at creating a Checkstyle 3.0 file for HttpClient, but I never got around to posting it. I don't think I covered all of the rules, but it's a start. I'll try attaching it to this email. -- Laura Ortwin Glück wrote: Cheers. Are you using Maven for this? I tried that yesterday (first time actually) but found that with a fresh maven installation, the maven tasks are broken. This is mainly caused by a new version of Checkstyle. They moved their configuration from flat properties format to XML. So we need to write a new checkstyle config file. I can do that next week. I will file a bug for that. Odi Michael Becke wrote: I'll redeploy the site. It seems that a number of apache urls(viewcvs and archives) have changed recently. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ?xml version=1.0 encoding=UTF-8? checkstyle-configurations file-format-version=1.0.0 check-configuration name=HttpClient rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.ConstantNameCheck severity=warning config-properties config-property name=format value=^[A-Z](_?[A-Z0-9]+)*$/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.EmptyBlockCheck severity=warning comment=try and finally must contain a statement config-properties config-property name=option value=statement/ config-property name=tokens value=LITERAL_FINALLY, LITERAL_TRY/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.EmptyBlockCheck severity=warning comment=catch must contain text config-properties config-property name=option value=text/ config-property name=tokens value=LITERAL_CATCH/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.FileLengthCheck severity=warning comment=2000 config-properties config-property name=max value=2000/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.IllegalImportCheck severity=warning comment=No sun.* imports config-properties config-property name=illegalPkgs value=sun/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.IllegalInstantiationCheck severity=warning comment=Use java.lang.Boolean constants config-properties config-property name=classes value=java.lang.Boolean/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.JavadocMethodCheck severity=warning comment=Require JavaDoc on methods and constructors config-properties config-property name=allowMissingParamTags value=false/ config-property name=allowMissingReturnTag value=false/ config-property name=allowMissingThrowsTags value=false/ config-property name=allowThrowsTagsForSubclasses value=false/ config-property name=allowUndeclaredRTE value=true/ config-property name=scope value=private/ config-property name=tokens value=METHOD_DEF, CTOR_DEF/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.JavadocTypeCheck severity=warning comment=Require JavaDoc on classes and interfaces config-properties config-property name=authorFormat value=/ config-property name=scope value=private/ config-property name=tokens value=CLASS_DEF, INTERFACE_DEF/ config-property name=versionFormat value=/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.JavadocVariableCheck severity=warning comment=Require JavaDoc on all variables config-properties config-property name=scope value=private/ /config-properties /rule-configuration rule-configuration classname=com.puppycrawl.tools.checkstyle.checks.LeftCurlyCheck severity=warning comment=Left curly brace at EOL config-properties config-property name=maxLineLength value=100/
Re: Grabbing a header from the server's response
Mark Castillo wrote: After sending a GET request to a server, how to I pick out the name/value of a specific header from the server's response? Call the getResponseHeader(String name) method (or one of its siblings) on the HttpMethod you used for the request, which is probably a GetMethod in this case. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SocketException : SSL Implementation not available
Roland Weber wrote: 3. your code does not work with IBM JDK 1.3 in WSAD with Sun JSSE FWIW, we were experimenting with the IBM JDK last year and got lots of mysterious JSSE failures. Finally we realized that we were still using Sun's JSSE implementation. Switching to the IBM JSSE for 1.3 fixed the problems. It's been long enough that I can't remember exactly what the symptoms were, but our verdict was that mixing and matching JDKs and JSSEs just didn't work. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HttpClient 2.0 RC1
+1 (nonbinding) from me Kalnichevski, Oleg wrote: We have had just one (what I see as a real) bug since 2.0 beta2. I think it is time we moved past 'beta' into 'final release' phase with 2.0 branch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: If it is just about release numbers, let us call it HttpClient 3.0 Amen. I'm not sure how much point there is in a 2.1 release if there's not allowed to be *any* API breakage. Maybe we should freeze the 2.0 stream and just put out 2.0.1, etc. bug fix releases and call the current main trunk 3.0 so that we can clean up some of this stuff. I think it might still pay to do some of it gradually, like the current exception fixes in 3.0 and the removal of the IOException inheritance in 4.0 so that the transitions are easuer. But I don't think we should be striving for 100% API compatibility in the next release. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding of special characters in request URI
Oleg Kalnichevski wrote: This is one of many 'shady' areas of the HTTP spec. Basically there is no standard way for the client to communicate to the server what coding has been used to decode query parameters. It's definitely shady. I've seen two approaches used here. In the past, many internationalized applications would assume that the non-ASCII encoded characters in submitted URIs were in the same character set as the page that was submitting the request. So if you know that you generated foo.jsp in Latin-5, then you assume that any URIs requests coming from foo.jsp should be treated as Latin-5 after being URL-decoded. There's a paper on this technique floating around somewhere, written by a guy I used to work with at IBM, but I can't find it on the Web. The more modern approach is to assume that the URI is always in UTF-8. If there are any non-ASCII characters in it after URL-decoding, then you run it through a UTF-8 converter (UTF-8 to UTF-16 in the case of Java). Here's a proposal on this: http://www.w3.org/International/O-URL-and-ident.html. If you follow the links from there you'll find other useful pages such as http://www.w3.org/International/questions/qa-forms-utf-8.html. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] exception handling revised
Oleg Kalnichevski wrote: 2) Go elaborate - org.apache.commons.lang.exception.NestableException (or equivalent) | +-- org.apache.commons.httpclient.HttpException (Root exception) I prefer this elaborate approach. (And I liked your inclusion of an InterruptedHttpException.) I don't think the dependency on commons-lang is really required, though. If we want to avoid it, we can just put the nesting support into our own root HttpException class. The only parts that are really required are a field to hold the nested exception, a couple of constructors, and an accessor for the nested exception. Of course, a few convenience methods would be nice too. Personally, I'm fine with a dependency on commons-lang; I just wanted to throw out an alternative if there turn out to be people who aren't. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
Oleg Kalnichevski wrote: Sadly enough, there's (there will be) no reliable way to interrupt a request in the release 2.0. It is an unfortunate oversight on our part. This feature is planned for the 2.1 release: This is a hard problem, because almost all of the calls in the old java.io library are non-interruptible. There's no good way to, for example, have a background thread whose job is to interrupt requests that have taken too long. In our current code, we fake interruptible threads by using (pooled) background threads to execute the requests. When the timeout interval expires, we give up on waiting for the background thread to finish the fetch and just throw a timeout exception. But I haven't found a way to make the background thread actually stop the fetch, so it just sits there until the socket timeout (if any) triggers an IOException. At that point we can recycle the thread back into the pool. This is very error-prone, though; I'm currently trying to track down a nasty synchronization bug in the threading. To make this feature work, we'd probably have to do something like this: - Add a timeout property to HttpMethod or HttpMethodBase - Just before executing a method, set an internal endTime property - Every time we're about to do a socket operation, e.g. in AutoCloseInputStream.read(), compare the current time and endTime. If we're past endTime, though an exception. If not, adjust the socket timeout so that the read operation can't go past endTime. - Do similar things while waiting on the connection pool, opening sockets, etc. Yuck. I keep thinking there *must* be a simpler way, but I haven't found it yet. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
Oleg Kalnichevski wrote: The observer thread simply closes the damn socket when the user hits the cancel button. Whuch. The communication thread immediately throws an IOException and happily terminates. Good idea! We could implement this in HttpClient by having one master observer thread whose job was to close a connection's socket whenever a Method using that connection has timed out. I also attempt to cleanly shutdown input/output streams ob the socket With HttpConnection.closeSocketAndStreams or its equivalent? -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to interrupt connexion ?
I wrote (in response to Oleg): Good idea! We could implement this in HttpClient by having one master observer thread whose job was to close a connection's socket whenever a Method using that connection has timed out. I messed with this today and got it more or less working. Since I didn't want to make any modifications to the HttpClient classes, at least for now, my timeout observer thread is just calling HttpConnection.close. It does indeed make anyone trying to read or write on the connection throw a SocketException, which turns into an HttpRecoverableException. My client code can then check to see if the timeout has elapsed and turn this into the VXML error.badfetch.timeout event if necessary. Just calling HttpConnection.close() probably isn't strictly correct. For one thing, it closes the streams before it closes the socket. If the foreground is actually doing something with the stream at the same time, this might cause an error when the stream gets closed out from under it. I think the proper sequence is to shut down the streams with Socket.shutdownInput and Socket.shutdownOutput if possible (in JDK 1.3 or later as Oleg said), then close the socket, then close the streams. To do this we'd have to add a new method to HttpConnection, maybe called abort() or some such, since there's no way to get at the socket and streams directly right now. I'll put together a patch for this and attach it to the bug when I have a chance. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Re: 2.0 release - deprecate some methods?
Adrian Sutton wrote: The flaw in the toUsingCharset method is two-fold: Firstly, Strings in Java are *always* stored internally as UTF-8 I agree with the rest of your analysis of this, but I thought I should point out that Java Strings and chars are stored in UTF-16 rather than UTF-8. A char is an unsigned, two-byte value that can hold all the characters from UCS2. As far as toUsingCharset goes, I agree that it looks broken. The code basically does: return new String(target.getBytes(fromCharset), toCharset); It's taking target, which is a UTF-16 string, encoding it into a byte array in fromCharset, and then decoding those bytes back into UTF-16 using toCharset. So it's pretendeing the bytes in the array have two different meanings, one when it writes them and one when it reads them immediately afterward. I can't see how this could be correct. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to post
Hi Nate, Jun 26, 2003 1:48:21 PM org.apache.commons.httpclient.HttpMethodBase processRedirectResponse INFO: Redirect requested but followRedirects is disabled ... I can just create a GetMethod and give it the url that would be redirected to, but how to get rid of that error message. Any suggestions? That's not really an error message, just a trace log that HttpClient writes to make it easier to figure out what's going on when a problem happens. You can control the logging level, send the logs to a separate file (or to the bit bucket), and so on. See http://jakarta.apache.org/commons/httpclient/logging.html for some info on how to do it. In your case, you might want to set the logging level to error so you only see messages for serious problems. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: form urlencoding, was Re: URI query escapes
Michael Becke wrote:
I propose that we:
- form urlencode values passed to
HttpMethodBase.setQueryString(NameValuePair[])
- use java.net.URLEncoder for form urlencoding
I agree, as long as URLEncoder seems to work.
Do you think we need to modify URI so that it uses URLEncoder to encode
the query part of URIs? In cases where a client has a URL string that
may or may not contain query parameters, it would lead to a slightly
more natural API usage:
HttpMethod meth = new GetMethod(new URI(urlString));
as opposed to
String query = null;
int index = urlString.indexOf('?');
if (index != -1) {
query = urlString.substring(index+1);
urlString = urlString.substring(0, index);
}
HttpMethod meth = new GetMethod(new URI(urlString));
meth.setQueryString(java.net.URLEncoder.encode(query));
or something like that, with error checking of course.
I'm not sure how much I care, though. If my fetching code had been
constructed using the HttpClient code from scratch, I wouldn't even have
the query parameters in the string in the first place; I'd just add them
with setQueryString.
I'll see if I can work up a preliminary patch for this stuff later
tonight or tomorrow morning.
Adrian Sutton wrote:
I know in the product we develop, we switched away from using
java.net.URLEncoder because it didn't work properly
FWIW, we're using it and haven't seen any problems. But we've been on
1.2 or higher since I started at BeVocal. (We're moving to 1.4 now
because the server VM performance is *much* better.)
--Laura
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI query escapes
Michael Becke wrote: Yes, but this is for application/x-www-form-urlencoded values. Currently we only assume this content type for post params (this was recently fixed). I think we have to assume it for get params too. In the HTTP 4.01 spec, 17.13.3.4 http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4: If the method is get and the action is an HTTP URI, the user agent takes the value of action, appends a `?' to it, then appends the form data set, encoded using the application/x-www-form-urlencoded content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes. So urlencoded seems like the right default for get query parameters. -- Laura BTW, how do you all feel about newsgroup posts in HTML format? I left this one in HTML because of all the links, but I'll stop if any of you have news readers that can't deal with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Order of things...
Ross Rankin wrote: I am getting inconsistent results on a few things and I realized I really am sort of parroting examples and really don't know the true order of things when doing a series of connections. So let me ask a few questions: What sorts of inconsistent results? 1) If doing to of the same type of requests what is the correct method for they type of action do I: a) use two Method variables This works. b) use the same one with a recycle but cast it new again What do you mean by cast it new again? Aside from that, this works; you can re-use HttpMethodMethod objects as long as you call recycle() first. After you call recycle(), the object is essentially virgin again, so you have to call setPath, re-set all of the headers, and so on. c) use the same one without a recycle but cast it new This won't work. You must call recycle() if you're going to re-use a HttpMethod object. d) use the same one with a recycle but use setPath between executes See the answer to b). 2) If doing a Post which returns another page do I need to really Get that page? No, if I understand the question correctly. If you're writing a browser-type application and the POST is a page-transition sort of POST, then the data for the new page/resource will be returned in the response to the POST. There's no need to follow it by a GET. Of course, someone *could* dream up a protocol layered on top of HTTP that required all POSTs to be followed by GETs, but I've never heard of one. 3) What the proper place for a method.releaseConnection? After the method, after you are all done? After you're finished reading from the method's input stream, I think. I'm not 100% sure about this one though, because this part of httpclient has changed a lot. 4) Once the client is set up and configured, do you need to do anything to maintain it? HttpClient isn't really a server that you set up or configure. It's just a class library that you call. So I don't really understand the question. 5) Rejected cookies. OK so the system I'm connecting to can not make a good cookie, can't I accept it anyway? You can experiment with the apache.commons.httpclient.cookiespec system property. By default, HttpClient uses the RFC2109 cookie policy, which is fairly strict. If you set this property to COMPATIBILITY, it will be more lenient and might accept the broken cookies from your server. See the code in org.apache.commons.httpclient.cookie.CookiePolicy for details. 6) Starting out, here the order I think is correct am I right? a) create a host configuration a) create a connection using that host config b) use that connection to create a connection Manager c) use that connection Manager to create a client d) create a Method e) execute that method using the host config and client Close. You don't need to create a connection yourself. Just create a connection manager (probably a MultiThreadedHttpConnectionManager) and then use that to create an HttpClient. The connection manager will create the connections itself, as needed. Then you create methods and execute them using your host config and client. Laura Werner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17487] - waitForResponse is using busywait
Oleg Kalnichevski wrote: Odi, are you sure you want to have an extra thread per HttpMethod? I do not think so You can do threads fairly efficiently by pooling them. I do it in my cache, since I have to allow a timeout on the whole transaction and abort the transaction even in the middle of reading the response if it takes too long. (The VoiceXML spec requires this.) But this is probably overkill for httpclient. Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug: News page has wrong date
Hi all, I just noticed a minor gotcha while showing someone at work the News page at http://jakarta.apache.org/commons/httpclient/news.html. The first item has the wrong date: 25 January 2003 rather than 25 February 2003. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Significant HttpClient HttpMethodBase overhaul. Need earlyfeedback
Hi all, I really like this refactoring. People like Laura should track the changes we make and rewrite their own client to either use or extend the HttpClient class. For the long run I think nobody should go without the HttpClient class. HttpClient should act a bit like a facade. Agreed on all counts. I too really like this refactoring, as I mentioned earlier.. However as mentioned earlier this refactoring should not go into the code base until 2.0 has been released. I have mixed feelings on this one. Our company has a large, carrier-grade VoiceXML/telephony system. We're just about to deploy a version that incorporates the 2.0a1 version of httpclient. As soon as that's done (and I'm no longer getting dragged into random debug fests in other areas), I'm going to look at upgrading our code to use the latest httpclient, and to give our HttpCache a cleaner API so that we can think about open sourcing it at some point in the future. My (long-winded) point is that I'd rather do this in one big step than in multiple small ones. From my point of view, it's fine if the redirect work goes into 2.0. Of course, that's probably because 2.0 is too late to make it into my current release, so I don't care if it gets delayed a little bit. Someone who has a release coming up in a couple of months might think differently. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Significant HttpClient HttpMethodBase overhaul. Need earlyfeedback
Michael Becke wrote: I think it would be possible to add cross site redirects at the HttpClient level without removing the other functionality from the HttpMethod. HttpClient would just need to check the status code and re-try. But, just because it is possible doesn't mean we should do it. If we have the go-ahead to implement this I'm all for it. I implemented it this way in my HttpCache code that sits on top of httpclient but doesn't use the HttpClient class. There's an outer loop in my cache's executeMethod, and it calls the inner loop in HttpMethodBase.execute. It got messy and was a bit hard to get right, but it worked. In general, I think it's cleaner to have all of the redirection and authentication handled in one loop, rather than having two separate ones. It just makes the architecture simpler. The only good reason I can see for going with a two-loop solution is the fact that we're fairly close to a final release right now and might want to keep the code stable. On the other hand, if we're going to make a semantic API change like this, it's probably better to do it now, before 2.0 final. -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The use of UTIUtil.toUsingCharset?
Oleg, I can't say I comletely agree with your point (or understand it), but so be it. Feel free to ask for clarification. Basically I was trying (in my wordy way) to say that toUsingCharset seems to do two things: - Convert the Unicode string to an array of bytes using the converter for fromCharset - Convert the bytes back to Unicode using the converter for toCharset. This makes no sense to me. When you're doing character-set-aware programming and have an array of bytes, you always need to keep a (byte[], charset name) pair, so you know what the bytes *mean*. The bytes by themselves are just a bit stream; the character set name tells you how to interpret the bits into abstract characters that mean something to a human. toUsingCharset is converting the Unicode string to a bit stream using one mechanism, then converting back to Unicode using another mechanism. I don't know how this could ever do anything useful. Had not Sung-Su refused to provide a simple unit test case for this method, this discussion would have been put to an end a few months ago. But apparently writing test cases is for losers How about if we just deprecate the @#% thing and the two URIUtil methods that call it? -- Laura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy-Connection: close header
Adrian Sutton wrote: Just run into a non-standards compliance problem with IIS proxies in certain configurations. At times instead of returning a Connection: close header, it returns a Proxy-connection: close header. For what it's worth, I've noticed that Squid sometimes uses a Proxy-Connection header as well. So whatever patch you come up with will probably be useful for more than just IIS. Laura Werner BeVocal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy-Connection: close header
Adrian Sutton wrote: Do you have any idea how to make squid use that header? I don't think we're doing anything special to make it happen. Here are the headers from a couple of typical transaction, with a few host names slightly obscured. This is using my own Java-based caching code on top of httpclient alpha 1. (I'm starting to upgrade to the latest version now). Try to fetch a resource from a machine the Squid proxy doesn't have access to: 16:49:30:311 HTTP request headers for jack.vxml: Host: privatemachine.bevocal.com User-Agent: BeVocal/2.4 VoiceXML/2.0 BVPlatform/1.8.0.6 16:49:30:326 HTTP response headers for jack.vxml: HTTP/1.0 503 Service Unavailable Proxy-Connection: close Expires: Thu, 20 Feb 2003 00:49:31 GMT Date: Thu, 20 Feb 2003 00:49:31 GMT Server: squid/2.5.STABLE1 Content-Length: 1285 X-Squid-Error: ERR_DNS_FAIL 0 Content-Type: text/html X-Cache: MISS from proxy01.x.bevocal.com Mime-Version: 1.0 Fetch from a resource it *does* have access to 16:51:52:537 HTTP request headers for jack.vxml: Host: www.somewhere.com User-Agent: BeVocal/2.4 VoiceXML/2.0 BVPlatform/1.8.0.6 16:51:52:662 HTTP response headers for jack.vxml: HTTP/1.0 200 OK Proxy-Connection: close Accept-Ranges: bytes Date: Thu, 20 Feb 2003 00:47:55 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b Content-Length: 14853 ETag: 19f7e5-3a05-3e3b1965 Last-Modified: Sat, 01 Feb 2003 00:48:37 GMT Content-Type: text/plain X-Cache: MISS from proxy01.x.bevocal.com Fetch the same resource again a minute or two later... 16:56:31:115 HTTP request headers for jack.vxml: Host: www.zenstarstudio.com User-Agent: BeVocal/2.4 VoiceXML/2.0 BVPlatform/1.8.0.6 16:56:31:115 HTTP response headers for jack.vxml: HTTP/1.0 200 OK Proxy-Connection: close Accept-Ranges: bytes Date: Thu, 20 Feb 2003 00:47:55 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b Content-Length: 14853 ETag: 19f7e5-3a05-3e3b1965 Last-Modified: Sat, 01 Feb 2003 00:48:37 GMT Age: 517 Content-Type: text/plain X-Cache: HIT from from proxy01.x.bevocal.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The use of UTIUtil.toUsingCharset?
Hi Sung-Gu, Actually, that's very easy... And not that important unless it's not going to be support multilinqual. As you see the diagram, bytes informations created from the original charset should be restored. That's all. My understanding of what you're saying is that if someone constructs a URI using escaped characters in a particular charset (e.g. Big-5), using the URI(char[] escaped) constructor, then URI needs to preserve those characters. If someone asks for the URI back as an escaped string in the original charset (e.g. Big-5 again), we need to give them the *exact* original string; it's not good enough to trancode from the escaped Big-5 string to Unicode and back to Big-5. Is this correct? If this is true, I have a few comments on why this matters... -- First, for those who don't understand why you can't just convert everything to Unicode and stop worrying, there is some sense behind this. When Unicode was invented, the far-east languages were Unified into the Han block of Unicode. Some characters that have distinct codes in the native double-byte character sets were mapped to single Unicode characters. This meant that some native character sets wouldn't round trip to Unicode and back. It was essentially a political compromise -- the Unicode folks needed to save space in the 64k base plane, so they merged Han characters that meant very similar things and looked almost exactly same. (Emphasis similar and almost.) But in native charsets that didn't need to have room for Korean and Cyrillic and all the other stuff that's in Unicode, there's room to split out multiple versions of these characters that are merged together. -- There are also a few new character sets like JIS-212 that contain characters (like Japanese dental symbols, believe it or not) that haven't been encoded in Unicode yet. Presumably we'd want to keep the encoded URI string around so that we can preserve this kind of character. (In a past life I managed the Unicode group at IBM, and I remember far more of this stuff than I thought I did.) A few comments on URI.java and URIUtil.java -- I think the comments need to be greatly improved. It's very hard to figure out what many of the methods do. In the cases where I can figure out what they do, it's hard to figure out *why*. -- It would be nice if the documentation explained the charset concepts: What is a document charset and a protocol charset and so on. A reference to the RFC is nice, but a more concice explanation in the JavaDoc would be better. Laura, hoping I helped answer part of the why here, at least - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using httpclient without a HttpClient object (was Redirects?)
Jeffrey Dever wrote: Is there anyone out there that has code that actually calls the HttpMethod.execute()? Anything that looks like this: HttpState state = new HttpState(); HttpConnection = new HttpConnection(host, port, secure); HttpMethod method = new GetMethod(path); int status = method.execute(state, connection); I do. I'm the one who doesn't use HttpClient at all, because it's too simplistic for me. I need to maintain a single HttpConnectionManager but a bunch of HttpState objects (one per thread in my application), so I have my own function that does the same thing as HttpClient.executeMethod. The function looks something like execute(HttpMethod method, HttpState state, HttpConnectionManager connections). It lets HttpMethod.execute() handle intra-site redirects, but when it gets a 303 response back from that method, it takes care of the inter-site redirects without returning to the caller. I think it would be OK to add the redirect functionality to HttpClient, but I think it should go into a public static method, so that it can be called by the normal HttpClient methods and by people like me. I can do the work on this if you want. Laura Werner BeVocal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Minor bug in checkstyle.properties
I just noticed a minor bug in checkstyle.properties. There are two settings for checkstyle.pattern.publicmember: checkstyle.pattern.publicmember=^f[A-Z][a-zA-Z0-9]*$ and checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$ I'm not submitting a patch because I'm not sure which one is correct. (I suspect it's the second one, though). Laura Werner BeVocal Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
