AW: Extra newline when using ByteArrayPartSource and FilePart

Thanks Oleg, but I found the issue...it definitely seems to be a problem on the server side. It turns out someone had reported a similar issue on the mailing list (Bug 20744). Somehow I had missed it in my previous searches. The problem is that whatever package or classes the server is using to h

Re: [SURVEY] Commons-URI or not? - jarring or ... and exposing some classes?

I'd like to consider the compelete opposite situation. If a project (knows what they exactly need) wanted just several classes from another project, should they include a whole jar from the project? What's the possbile solution? Here you are, my one... You can notice there are xxx.md5, xxx.asc

Re: [SURVEY] Commons-URI or not? - with java.net.URI?

> - Original Message - > From: "Shapira, Yoav" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, June 25, 2003 9:38 PM > Subject: RE: [SURVEY] Commons-URI or not? > > Howdy, > I think a slightly more detailed proposal is needed: one that add

Re: 2.0 release

On Thursday, June 26, 2003, at 03:10 PM, Jandalf wrote: I see that beta 1 is out which is fantastic. Can somone post a update on where we stand for a upcoming final release? My current list of things to do: * Add testimonials page * Add clover report * FilePart with autodetecting mime type. * L

DO NOT REPLY [Bug 20986] - Contributed utility for determing content type from file type extension

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

2.0 release

I see that beta 1 is out which is fantastic. Can somone post a update on where we stand for a upcoming final release? Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [SURVEY] Commons-URI or not? - about its needs

- Original Message - From: "Eric Johnson" <[EMAIL PROTECTED]> > I too am against a separate URI commons package, at least for the moment. [snip] > Anyway, to the extent that a separate URI package would make sense, if > we had a model such as the above, where most people used the one g

Re: [SURVEY] Commons-URI or not?

The Guidelines of the commons charter has some guidance here: http://jakarta.apache.org/commons/charter.html 1. The primary unit of reuse and release is the package. 2. The package library is not a framework but a collection of components designed to be used independently. 3. Each pack

Re: [SURVEY] Commons-URI or not? - about starting point

- Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Cc: "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Thursday, June 26, 2003 2:37 AM Subject: Re: [SURVEY] Commons-URI or not? > > > On Wed, 25 Jun 2003, Sung-G

Re: Poof!

Excellent! Welcome back Jandalf and congrats on the sale and the new job! You must now be Jandalf the White and have some thrilling stories about killing that balrog. :) Regards, Adrian Sutton. On Thursday, June 26, 2003, at 02:39 PM, Jandalf wrote: Hello all! My house has sold, I've move

Poof!

Hello all! My house has sold, I've moved to Calgary and I have a new job. All is well. I've been monitoring the list and have been taking care of the moderate messages, but I'm back to start participating again. Jandalf. - T

Re: [SURVEY] Commons-URI or not?

On Wed, 25 Jun 2003, Eric Johnson wrote: > [snip] > One of the negatives that others have mentioned on the HttpClient list > is the growing dependency problem within the Apache projects, > particularly with the myriad of dependencies on commons projects, and > among the commons projects themselv

Re: [SURVEY] Commons-URI or not?

On Wed, 25 Jun 2003, Sung-Gu wrote: > > Hi all, > > I suggest that jakarta-commons provides flexible URI issue implementations > as a package. > > Various applications using URI concept comes in the internet world. and > they need common mechanisms and algorithms for URI. > > For example, all

RE: [SURVEY] Commons-URI or not?

I like this idea. I would also propose: o This "commons.jar", "commons-all.jar" or whatever it should be called be part of the nightly-build. If a sub-component's build failed, then this build fails. o A release of commons-all would be automatically attempted when a new release of a sub-component

Re: HTTP client caching

Adrian Sutton wrote: I would actually think that a nice generic caching library would be very beneficial, but it should definitely be outside of HttpClient as HttpClient is very regularly used without any desire for caching at all. Agreed on both counts. I have a caching library that sits on to

HttpClient Article

Feel good moment for you all. As part of an article on the entire jakarta-commons project, HttpClient got a mention with a very positive review: http://www.onjava.com/pub/a/onjava/2003/06/25/commons.html?page=3 The beginning of the article is at: http://www.onjava.com/pub/a/onjava/2003/06/25/c

Re: HTTP client caching

well, a vacuum cleaner is indeed a bit far off ;-). However, I think that implementing an Http Client (i.e. a browser emulator without rendering engine) should be much closer to HttpClients purpose. I would actually think that a nice generic caching library would be very beneficial, but it shoul

Re: HTTP client caching

My impression was that Laura had implemented some kind of caching mechanism. Laura, is that true or am I hallucinating again:) ? Mike On Wednesday, June 25, 2003, at 03:22 PM, Christian Sell wrote: hello all, I am looking for a library to implement browser-like behavior, including HTTP 1.1 c

Re: HTTP client caching

> What I find a little disappointing is the fact that I am faced with > almost unsurmountable obstacles in doing this (i.e., if I want to avoid > hacking the code). Maybe someone with a better understanding of the > architecture has a suggestion.. > Believe me, I am also REALLY unhappy with t

Re: HTTP client caching

Oleg Kalnichevski wrote: 1. Has it ever been considered to implement this as part of HttpClient? Yes, it has and the idea has been turned down, if my memory does not fail me. The consensus was that HttpClient should remain a HTTP communication library and would not attempt to evolve into a brows

performance

I will appreciate if anyone answers my questions below. -Does anyone has perfromance comparison between HTTPClient and JDK HttpURLConnection? -Are there any performance techniques that can be used to improve the performance of HTTPClient? -When will the final version of HTTPClient be out? Than

Re: HTTP client caching

Christian, Let me present my take on these issues (See below): On Wed, 2003-06-25 at 21:22, Christian Sell wrote: > hello all, > > > I am looking for a library to implement browser-like behavior, including > HTTP 1.1 conformat caching. I have 2 questions regarding HttpClient: > > 1. Has it ev

invalid response code/body

I've looked in Bugzilla and the list archives to find a comparable issue, but have been unsuccessful at finding a similar circumstance. If someone recognizes the problem and has an implementation solution, I would be very grateful for any suggestions you could provide. I'm experiencing a problem w

Re: Client Auth / Certificates

Matt, No, there's no such mechanism in place. However, there's a way provide a custom SSL implementation that meets your specific needs. Have a look at the HttpClient SSL guide at the following location: http://jakarta.apache.org/commons/httpclient/sslguide.html There's a section on customising

HTTP client caching

hello all, I am looking for a library to implement browser-like behavior, including HTTP 1.1 conformat caching. I have 2 questions regarding HttpClient: 1. Has it ever been considered to implement this as part of HttpClient? 2. I have seen an archiecture in JTidy (w3c.org), which I find quite

RE: Extra newline when using ByteArrayPartSource and FilePart

Aaron, I am afraid it is premature to draw such a conclusion. I will double-check that it is not a bug in HttpClient and get back to you as soon as I can. Oleg On Tue, 2003-06-24 at 18:15, Fa. MSG Hr. Liebling wrote: > After looking at the spec, the actual request looks ok (there should be 2 > n

Client Auth / Certificates

Hello All, I a nub to HttpClient. I am looking for a way to specify a particular client SSL certificate for Client Authenticated SSL. I do not see anything in the HttpClient javadocs, so I'm posting the question here. Is there such a mechanism already in place in HttpClient, or do I need to

Re: automatic management of cookie

Amit, Yes, I think Oleg is correct. You need to perform a get from the server before the post so that a cookie is set. Doing a get on http://www2.ipdl.jpo.go.jp/beginner_tm/TM_AREA.cgi set the following cookie: Set-Cookie: Name=BE21056561003 StartTime=2003/06/26 02:10:03 domain=jpo.go.jp Pat

Re: dependency hell

Hello all, Concerning the "dependency hell" thread (that I sort of started on httpclient's list), I would favour an "all-in-one, large .jar" approach as suggested by Eric Johnson, because it should keep all versions and internal dependencies nicely in sync, even if it complicates the release cycl

RE: automatic management of cookie

Have you checked all the responses? Our site uses javascript to determine if the browser supports cookies. If the javascript cannot store a cookie then further requests are rejected. Ralph - To unsubscribe, e-mail: [EMAIL PR

Re: [SURVEY] Commons-URI or not?

It would seem that most if not all of the responses from the HttpClient crew responded only to the HttpClient list, and not to commons dev. So I'm not sure that all that might need/want to see the entirely negative feedback have seen it. I don't subscribe to commons-dev, so if this doesn't ge

Re: Logging guide

AFAIK, Log4j doesn't have a separate TRACE level, so all TRACE logs actually end up as DEBUG logs. So at least for Log4j users, there's no difference. Just FYI. -chris Oleg Kalnichevski wrote: I fully agree. In 99% cases TRACE log produces no useful information. I even usually grep through the l

Re: Logging guide

Oleg Kalnichevski wrote: I fully agree. In 99% cases TRACE log produces no useful information. I even usually grep through the logs excluding TRACE entries in order to make them comprehensible. Oleg Patch to xdocs applied. The web will reflect the changes when it is next generated. Odi ---

Re: [SURVEY] Commons-URI or not?

Chris, This problem is as old as software engineering itself. Code reuse provides many benefits as well as many potential problems such as versioning conflicts. In my opinion benefits still outweigh the problems. Usually code reuse done right results in higher code quality, provided that you get m

Re: Logging guide

I fully agree. In 99% cases TRACE log produces no useful information. I even usually grep through the logs excluding TRACE entries in order to make them comprehensible. Oleg On Wed, 2003-06-25 at 10:42, Ortwin Glück wrote: > I think we should change the logging guide to set the log level to DEB

RE: automatic management of cookie

Amit, Sorry. It is indeed the log I was asking about. If you cookie theory is right, I think before you execute POST request you have to make sure that you get the cookie set by the target host. You should execute a GET request to a URL that returns the cookie that the target host expects to fin

Logging guide

I think we should change the logging guide to set the log level to DEBUG for org.apache.commons.httpclient. Currently it is set to TRACE and users seem to leave it like this. Oleg, do you find this TRACE level bloated logs useful? I think in the majority of cases a DEBUG level output is suffici

RE: automatic management of cookie

Hello Oleg, Thanks for your response. > However, it is just a guess. We will be able to give more definitive > answers if you provide us with the wire log of the HTTP session in > question. The file I attached in my last message in reply of Michael's comment isn't that the log? That file contai

RE: automatic management of cookie

Amin, It is not quite clear what is going on there. My best guess it that the cookie sent by the target host is malformed and as such rejected by HttpClient. However, it is just a guess. We will be able to give more definitive answers if you provide us with the wire log of the HTTP session in que

Re: [SURVEY] Commons-URI or not?

Chris Brown wrote: We're now finding it very difficult to use a lot of Jakarta projects, because of "dependency hell"... it's becoming worse than Microsoft's famous "DLL hell" problem. You can work around the DLL hell by using different class loaders for different Jakarta tools. Odi BTW the DL

RE: [SURVEY] Commons-URI or not?

As a user of jakarta projects I must say I agree with Chris on this one. No offense, but in the way I see it HttpClient isn't "big enough" to be splitted and to have one more dependency. I met the same trouble as Chris for commons-logging, helpfully most jakarta projects are willing to update t

Re: [SURVEY] Commons-URI or not?

Please NO !!! We're now finding it very difficult to use a lot of Jakarta projects, because of "dependency hell"... it's becoming worse than Microsoft's famous "DLL hell" problem. The more self-contained you can keep an API, the better ; yes, there are issues concerning code re-use, but at prese