Re: Relative URIs strike again

On Wednesday, January 29, 2003, at 08:42 PM, Michael Becke wrote: These cases are partially handled as of now. "" Does not work, but should. This falls into the case of abnormal URIs according to the RFC. I think Armando was working on a fix for this. Btw, here is an example of an empty URI

Re: Relative URIs strike again

But what exactly is the correct behaviour? At least two major browsers implement this behaviour in a different way than you would immediately expect. This could just be a bug in them, or it could be a legitimate ambiguity. To clarify, which of the following do you interpret as the correct behav

Re: Relative URIs strike again

Michael Becke wrote: But what exactly is the correct behaviour? At least two major browsers implement this behaviour in a different way than you would immediately expect. This could just be a bug in them, or it could be a legitimate ambiguity. To clarify, which of the following do you interpr

Re: Relative URIs strike again

In the case of "#" it would seem this has a defined fragment component which is empty (with all other components undefined). I agree. Fortunately this case seems to be handled correctly. I'll send a patch that adds a few test cases in a minute. Presumably then, for the above case of "#",

[PATCH] test URI

The attached patch adds the following test cases to TestURI: URI.URI( "http://a/b/c/d;p?q";, "#" ) URI.URI( "http://a/b/c/d;p?q";, "" ) Mike Index: test/org/apache/commons/httpclient/TestURI.java === RCS file: /home/cvspublic/j

Not giving ourselves enough credit on the home page

Based on the recent URI discussion, and some other points, it strikes me that we could take a little more credit for the work that has gone into HttpClient. On the HttpClient home page (http://jakarta.apache.org/commons/httpclient/index.html) four RFCs are listed. Given all the discussion abo

Re: Not giving ourselves enough credit on the home page

Eric Johnson wrote: [ ... ] Someone posted recently that HttpClient appears to be faster than the corresponding Sun solution. I don't think Sun's is the one to beat. The innovation.ch one is not bad, though getting pretty old. You may want to do a comparison with what the jakarta one can do

Re: Re: Not giving ourselves enough credit on the home page

I was always under the impression that the Sun's Brazil small footprint HTTP stack is a fast implementation in Java.: http://research.sun.com/brazil/ One could also go beyond Java (e.g. libwww or LibWWW or ...) Otis On Thu, 30 Jan 2003, Mike Moran ([EMAIL PROTECTED]) wrote: > Eric Johns

RE: Not giving ourselves enough credit on the home page

Hi, Based on the Http-client library a WebDAV API was developed (Jakarta slide). There are plans to implement JSR 147 (a standard Delta-V API) based on this implementation (currently not finally confirmed). Best regards, Juergen -Original Message- From: Mike Moran [mailto:[EMAIL PR

[PATCH] PostMethod & PutMethod revision (take 2)

Bug fixes: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11095 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11653 Changelog: - Abstract EntityEnclosingMethod class has been introduced to encapsulate common behaviour of all entity enclosing methods - Expect: 100-continue" support - Htt

DO NOT REPLY [Bug 16429] - Align the code base with checkstyle

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Bug 16429: Align the code base with checkstyle

Patch five (in bugzilla) fixes the last of the simple checkstyle warnings. http://issues.apache.org/bugzilla/show_bug.cgi?id=16429 The URI class has some variables that I can't provide javadoc for because quite simply, I don't understand what they're used for. There are some comments there but

Re: [PATCH] test URI

Committed. Cheers, Mike Oleg On Thu, 2003-01-30 at 18:20, Michael Becke wrote: > The attached patch adds the following test cases to TestURI: > >URI.URI( "http://a/b/c/d;p?q";, "#" ) >URI.URI( "http://a/b/c/d;p?q";, "" ) > > Mike > > ___

Re: Bug 16429: Align the code base with checkstyle

There are lots of TODO: comments in the code. There were also a bunch of FIXME: comments which I've changed to "TODO" because checkstyle will warn us about TODO but not FIXME. Longer term we should probably change checkstyle to look for FIXME as well but for now it was easier to change those

DO NOT REPLY [Bug 8353] - optimization in sending request

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug

DO NOT REPLY [Bug 10817] - Provide more Example Code

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 10817] - Provide more Example Code

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Bug 16429: Align the code base with checkstyle

> Well, the @see tags in question are so long because they refrence the > fully qualified class name. Javadoc is aware of the package space and > only requires a fully qualified name if there is a namespace conflict. > Might as well just use the short form in the source as the generated > files co

DO NOT REPLY [Bug 16625] - Ensure the features.html and index.html adequately give httpclient enough credit

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Not giving ourselves enough credit on the home page

All good points. I had not yet had a chance to update those documents. Its great to have input from everyone as the content is the hardest part. I created a bug report for it and am refrencing back to this mail thread. http://issues.apache.org/bugzilla/show_bug.cgi?id=16625 BTW: anyone can subm

DO NOT REPLY [Bug 12244] - Response Header ordering not preserved from the server

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 12244] - Response Header ordering not preserved from the server

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [PATCH] PostMethod & PutMethod revision (take 2)

1) I'm sure stuff like this is unintentional: - * @author Ortwin Glück - * @author mailto:[EMAIL PROTECTED]";>Mike Bowler + * @author Ortwin Glück 2) I thought we had deprecated the "use disk" methods in GetMethod, but I don't see it that way in the source. Didn't we agree that those methods w

Re: [PATCH] PostMethod & PutMethod revision (take 2)

7) About Mikes idea for having two different classes for stream posting and parameters posting. I don't really like what that does to the public interface. Its already fat when it comes to parameters, and conceptually it is just a POST method. Here is another idea. Using streams is the genera

Re: [PATCH] PostMethod & PutMethod revision (take 2)

Do you envision multiple calls to setRequestBody() still causing an IllegalStateException. On appearances, setRequestBody() looks like a setter method. I would not expect a setter method to throw an exception because I called it twice, I would expect it to just overwrite the previous value an

deployed website - new javadoc links

I rebuild and redeployed the website. The cool change of significance is the javadocs now link internally to j2sdk1.4.1 and commons-logging online javadocs. So if a method returns a String, it does not show up as java.lang.String, but as hyperlink to the String documentation. -jsd -