Any possibility of including fixes for HTTPCLIENT-1266 and HTTPCLIENT-1268 in the 4.2.3 release?

Hi folks, ManifoldCF's current release is planned for 12/31/2012. It would be great if that release could include fixes for the NTLM issues mentioned above. ManifoldCF currently builds/runs against HttpClient 4.2.2. Who is doing the release planning for 4.2.3, and what would your thinking on

Re: Any possibility of including fixes for HTTPCLIENT-1266 and HTTPCLIENT-1268 in the 4.2.3 release?

On Sat, Dec 8, 2012 at 8:04 AM, Oleg Kalnichevski ol...@apache.org wrote: On Sat, 2012-12-08 at 05:15 -0500, Karl Wright wrote: Hi folks, ManifoldCF's current release is planned for 12/31/2012. It would be great if that release could include fixes for the NTLM issues mentioned above

Re: [Fwd: Re: Mandatory svnpubsub migration by Jan 2013]

That is what you need to do, yes. Karl On Mon, Dec 10, 2012 at 5:30 AM, Oleg Kalnichevski ol...@apache.org wrote: Folks If any of you has any practical experience with migration to svnpubsub, please confirm my understanding that the absolute minimum expected from us to be considered

Re: NTLM internal engine vs JCIFS

It may well be the right thing to do. The implementation is certainly on par with jCIFS right now. The jCIFS implementer, in fact, has been reducing NTLM support in that library to bare minimum over time, because he has a for-profit venture to sell his real implementation. So, for instance,

Re: NTLM internal engine vs JCIFS

I will happily have a go at it, probably Friday or this weekend. Karl On Wed, Dec 12, 2012 at 12:13 PM, Oleg Kalnichevski ol...@apache.org wrote: On Wed, 2012-12-12 at 07:27 -0500, Karl Wright wrote: It may well be the right thing to do. The implementation is certainly on par with jCIFS

Re: NTLM internal engine vs JCIFS

Just updated ntlm.apt. Did I do this correctly? Do you agree with the content? It doesn't seem that tickets are typically used in this project to track documentation changes - do I have that right? Thanks! Karl On Wed, Dec 12, 2012 at 12:39 PM, Karl Wright daddy...@gmail.com wrote: I

Re: NTLM internal engine vs JCIFS

ok, done. Karl On Fri, Dec 14, 2012 at 9:13 AM, Gary Gregory garydgreg...@gmail.com wrote: I think it is good to track it because users will know to check for updated information when looking at the release notes. Gary On Fri, Dec 14, 2012 at 9:07 AM, Karl Wright daddy...@gmail.com wrote

NTLM work is done

Hi Oleg, FWIW, I received confirmation today that the work on NTLM is complete, and tested. So if that was holding up a 4.2.3 release, it should no longer. Thanks! Karl - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org

Re: Release notes for the upcoming HttpClient 4.2.3

Thanks - please let me know when you think you are done, and I'll amend accordingly. Karl On Fri, Jan 4, 2013 at 8:44 AM, Oleg Kalnichevski ol...@apache.org wrote: Karl et al This is to let you know that I am about to start working on cutting the 4.2.3 release. I am not much of a writer

Re: Release notes for the upcoming HttpClient 4.2.3

It already looks sufficient to me. Thanks! Karl On Fri, Jan 4, 2013 at 9:44 AM, Oleg Kalnichevski ol...@apache.org wrote: On Fri, 2013-01-04 at 09:41 -0500, Karl Wright wrote: Thanks - please let me know when you think you are done, and I'll amend accordingly. I am. It is all yours

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC1

I downloaded the binary image for the RC, built ManifoldCF trunk against this, and ran all tests successfully. +1 (non-binding) from me. Karl On Sun, Jan 6, 2013 at 2:13 PM, Oleg Kalnichevski ol...@apache.org wrote: Please vote on releasing these packages as HttpComponents Client 4.2.3. The

Kerberos support/krb5.ini file

Hi all, Does anyone have insight as to why Kerberos support is written to require krb5.ini, rather than including krb5.ini access as an implementation of an abstract in-memory way of providing tickets? This seems out of character with the rest of HttpComponents. Thanks in advance, Karl

Re: Kerberos support/krb5.ini file

Perhaps someone should complain to Oracle. ;-) But I agree nothing can be done at the moment. Karl On Mon, Jan 7, 2013 at 6:26 AM, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2013-01-07 at 05:16 -0500, Karl Wright wrote: Hi all, Does anyone have insight as to why Kerberos support

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

-1 from me (not binding), due to HTTPCLIENT-1296. :-( Karl On Tue, Jan 8, 2013 at 4:19 PM, Oleg Kalnichevski ol...@apache.org wrote: Please vote on releasing these packages as HttpComponents Client 4.2.3. The vote is open for the at least 72 hours, and only votes from HttpComponents PMC

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

It's apparently the result of a fix for HTTPCLIENT-1092. I am not sure when exactly that went in though. Karl On Wed, Jan 9, 2013 at 9:19 PM, sebb seb...@gmail.com wrote: On 10 January 2013 01:51, Karl Wright daddy...@gmail.com wrote: -1 from me (not binding), due to HTTPCLIENT-1296

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

I checked in a fix and a test on trunk. Somebody please let me know if the fix/test will be indeed going into 4.2.3. Thanks! Karl On Wed, Jan 9, 2013 at 9:41 PM, Karl Wright daddy...@gmail.com wrote: It's apparently the result of a fix for HTTPCLIENT-1092. I am not sure when exactly

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

Confirmed that it IS a regression, but that the regression has been around since 4.1.2. Karl On Wed, Jan 9, 2013 at 9:49 PM, Karl Wright daddy...@gmail.com wrote: I checked in a fix and a test on trunk. Somebody please let me know if the fix/test will be indeed going into 4.2.3. Thanks

Re: Release called off; Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

All set now; code committed with tests. Karl On Thu, Jan 10, 2013 at 4:41 AM, Oleg Kalnichevski ol...@apache.org wrote: Release called off due to HTTPCLIENT-1296. Oleg On Wed, 2013-01-09 at 21:49 -0500, Karl Wright wrote: I checked in a fix and a test on trunk. Somebody please let me know

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

know. Karl On Thu, Jan 10, 2013 at 7:56 AM, Oleg Kalnichevski ol...@apache.org wrote: On Thu, 2013-01-10 at 11:42 +, sebb wrote: On 10 January 2013 02:51, Karl Wright daddy...@gmail.com wrote: Confirmed that it IS a regression, but that the regression has been around since 4.1.2. Thanks

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

AM, Oleg Kalnichevski ol...@apache.org wrote: On Thu, 2013-01-10 at 08:13 -0500, Karl Wright wrote: The reason it was critical to ManifoldCF was only because we use the default host with virtual host feature fairly extensively. Working around it is possible but would require a lot of work

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

at 08:38 -0500, Karl Wright wrote: Thanks. I don't mind if the virtual host feature goes away, as long as there is some documentation about the right way to do the same thing. What it seems to boil down to is whether or not HttpClient attempts to set the Host header, and what it puts

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC2

Ok, that works for me. Karl On Thu, Jan 10, 2013 at 8:59 AM, Oleg Kalnichevski ol...@apache.org wrote: On Thu, 2013-01-10 at 08:52 -0500, Karl Wright wrote: But web crawlers often cache the dns step and use an IP address instead for the host name. In that case the host header is critical. I

Re: [VOTE] HttpComponents Client 4.2.3 release based on RC3

Once again, ran all ManifoldCF tests, which passed. +1 (nonbinding) from me. Karl On Fri, Jan 11, 2013 at 1:46 PM, Oleg Kalnichevski ol...@apache.org wrote: [x] +1 Release the packages as HttpComponents Client 4.2.3 Oleg On Thu, 2013-01-10 at 23:32 +0100, Oleg Kalnichevski wrote: Please

Re: [VOTE][RESULT] HttpComponents Client 4.2.3 release based on RC3

-at- apache.org * Oleg Kalnichevski olegk -at- apache.org * Karl Wright kwright -at- apache.org ant elder antelder -at- apache.org * Asankha C. Perera asankha -at- apache.org * no other votes * binding votes Original voting thread: http://mail-archives.apache.org/mod_mbox/hc-dev/201301.mbox

Strange behavior - does this sound familiar to anyone?

Hi all, For the ManifoldCF release, we've been having problems with our Solr connector, which uses Solrj which in turn uses HttpComponents/HttpClient to connect to Solr. The behavior we've been seeing is that when multiple document uploads to Solr are taking place at the same time, we see

Re: Strange behavior - does this sound familiar to anyone?

at 10:41 AM, Asankha C. Perera asan...@apache.org wrote: Hi Karl Is Solr hosted on Tomcat? and is Tomcat under any load / or properly tuned to handle such load? How frequently does this occur? regards asankha On 01/22/2013 07:44 PM, Karl Wright wrote: Hi all, For the ManifoldCF release

Re: Strange behavior - does this sound familiar to anyone?

a sizable TCP / Wireshark dump to investigate why one party is closing its side of the TCP connection regards asankha On 01/22/2013 10:08 PM, Karl Wright wrote: This happens both under Tomcat and under Jetty. It happens sometimes when only two documents are being indexed at the same time, so

Re: Strange behavior - does this sound familiar to anyone?

Thanks, Oleg. I was already aware of that. Architecturally it should not be possible to share HttpClient objects among threads in this situation. Karl On Wed, Jan 23, 2013 at 5:56 AM, Oleg Kalnichevski ol...@apache.org wrote: On Tue, 2013-01-22 at 09:14 -0500, Karl Wright wrote: Hi all

Re: Strange behavior - does this sound familiar to anyone?

: If this is not related to load, you could collect a sizable TCP / Wireshark dump to investigate why one party is closing its side of the TCP connection regards asankha On 01/22/2013 10:08 PM, Karl Wright wrote: This happens both under Tomcat and under Jetty. It happens sometimes when only two documents

Re: [Fwd: Re: NTLM issues with 4.2.3]

Yes - and more information too: (1) I need to know some details about how jcifs is being used when it is successful. Specifically, the question is whether you supply any -D jcifs configuration switches. If *no* switches or system property overrides are being supplied, that is also useful.

Re: [Fwd: Re: NTLM issues with 4.2.3]

There's enough info in the capture data provided to tell me the answer to the jcifs lmCompatibility question, I think. I'd still like to know the answer to question (2) though. Thanks! Karl On Fri, Feb 15, 2013 at 8:53 AM, Karl Wright daddy...@gmail.com wrote: Yes - and more information too

Re: [Fwd: Re: NTLM issues with 4.2.3]

, 2013 at 9:40 AM, Karl Wright daddy...@gmail.com wrote: There's enough info in the capture data provided to tell me the answer to the jcifs lmCompatibility question, I think. I'd still like to know the answer to question (2) though. Thanks! Karl On Fri, Feb 15, 2013 at 8:53 AM, Karl Wright

Re: NTLM issues with 4.2.3

Jason and I have taken this conversation offline; we're going to try out a couple of things and see what they do. Karl On Fri, Feb 15, 2013 at 10:00 AM, Jason Millard jsm...@gmail.com wrote: Yes I will definitely be willing to do this! Jason On Friday, February 15, 2013, Karl Wright wrote

Re: NTLM issues with 4.2.3

, February 15, 2013, Karl Wright wrote: Without the ability to duplicate the server-side setup here, the best I can do is change what seems to be different and ask you to try it in your environment, until it works there. The flag differences seem unimportant at first glance, but that is where I

Re: NTLM issues with 4.2.3

. Please let me know what happens with this new code. Karl On Fri, Feb 15, 2013 at 3:42 PM, Karl Wright daddy...@gmail.com wrote: FWIW, it does not appear to be a flag issue. I'll be looking deeper this weekend to see if I can find anything wrong with the encryption logic. Odd that that should

Re: NTLM issues with 4.2.3

I think I'm pretty certain it is #1. I'm going to check in fixes to this into both the branch and into trunk, and flag the HTTPCLIENT-1315 ticket also as being potentially fixed, since this could easily be the problem with that situation as well. Karl On Sun, Feb 17, 2013 at 11:32 AM, Jason

Disabling retries

Hi all, We have code that creates a DefaultHttpClient instance for use with Solr. The HttpEntity that is created when sending data is not reusable, so we've disabled retries (we thought) using the following code: DefaultHttpClient localClient = new

Re: Disabling retries

that causes this exception, perhaps erroneously. I'll provide further details, and if warranted a ticket and a fix, when I have them. Karl On Fri, Mar 8, 2013 at 7:13 AM, Oleg Kalnichevski ol...@apache.org wrote: On Thu, 2013-03-07 at 08:39 -0500, Karl Wright wrote: Hi all, We have code that creates

Re: Disabling retries

of authentication being required, etc. Please clarify if I am incorrect about that. Karl On Fri, Mar 8, 2013 at 7:21 AM, Karl Wright daddy...@gmail.com wrote: After looking at the code, I've asked the client to turn on an appropriate logger to see what is going on in his case. The symptom

Re: Disabling retries

: On Fri, 2013-03-08 at 07:27 -0500, Karl Wright wrote: Just to be as specific as possible, here is a portion of the trace: Caused by: org.apache.http.client.ClientProtocolException at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:909

Re: Disabling retries

an inputstream handed to them, not a file. But I was asking this question to see if anyone knew why a resettable input stream wouldn't work. Because, it doesn't seem to. Thanks, Karl On Fri, Mar 8, 2013 at 9:48 AM, Oleg Kalnichevski ol...@apache.org wrote: On Fri, 2013-03-08 at 09:07 -0500, Karl

Re: Disabling retries

-03-08 at 11:50 -0500, Karl Wright wrote: Trying again on a reply - google seems to have deleted my previous attempt. This is what the 'expect-continue' handshake is for. It enables the client to verify server expectations prior to sending the request body. Is there a reason this isn't getting

Re: Disabling retries

there's a configuration problem, or improperly coded webapp. But in any case the fix looks correct. Thanks again! Karl On Mon, Mar 11, 2013 at 10:07 AM, Karl Wright daddy...@gmail.com wrote: We tried enabling expect-continue but we're still getting the same behavior. This is a bit of a surprise

Re: Disabling retries

To finish up this thread, it seems that Resin is the problem. It sends TWO status lines - a 100 Continue AND a 401 Unauthorized in the same response in this situation. An obvious garden-variety bug, which we'll report to the Resin people ASAP. Karl On Mon, Mar 11, 2013 at 11:26 AM, Karl Wright

Re: Disabling retries

...@apache.org wrote: On Mon, Mar 11, 2013 at 01:44:06PM -0400, Karl Wright wrote: To finish up this thread, it seems that Resin is the problem. It sends TWO status lines - a 100 Continue AND a 401 Unauthorized in the same response in this situation. An obvious garden-variety bug, which we'll

4.2.4 release plans?

Hi Oleg, Any chance of a 4.2.4 release before April 15? Karl - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org

Still on-track to release HttpClient 4.2.4 by April 15?

Hi Oleg, I saw the release of HttpCore 4.2.4 go by - which was good news. I was wondering if you were still on track to release HttpClient 4.2.4 by mid-April? I'm winding down the MCF 1.2 release now. Thanks! Karl

Re: [VOTE] HttpComponents Client 4.2.4 release based on RC1

Ran all MCF tests on it. +1 from me (non-binding). Karl On Fri, Apr 5, 2013 at 2:28 PM, Oleg Kalnichevski ol...@apache.org wrote: Please vote on releasing these packages as HttpComponents Client 4.2.4. The vote is open for the at least 72 hours, and only votes from HttpComponents PMC

Re: [VOTE] HttpComponents Client 4.2.5 release based on RC1

Tried these out with the ManifoldCF test suite. +1 from me. Karl On Sun, Apr 21, 2013 at 3:55 PM, sebb seb...@gmail.com wrote: On 19 April 2013 17:42, Oleg Kalnichevski ol...@apache.org wrote: Please vote on releasing these packages as HttpComponents Client 4.2.5. The vote is open for

HTTPCLIENT-1350

Hi Oleg, I know you were working on state cleanup for the 4.2.5 release. I think HTTPCLIENT-1350 may be related to this. Would you be willing to have a quick look, and recommend debug logging options so that we can get what you think is needed to figure out the issue? Thanks! Karl

Re: HTTPCLIENT-1350

, Oleg Kalnichevski ol...@apache.org wrote: On Tue, 2013-05-07 at 06:57 -0400, Karl Wright wrote: Hi Oleg, I know you were working on state cleanup for the 4.2.5 release. I think HTTPCLIENT-1350 may be related to this. Would you be willing to have a quick look, and recommend debug

Re: HTTPCLIENT-1350

By default, I'd make it the same as the socket timeout. Makes sense, no? Karl On Tue, May 7, 2013 at 8:26 AM, Oleg Kalnichevski ol...@apache.org wrote: On Tue, 2013-05-07 at 08:03 -0400, Karl Wright wrote: Thanks - this allowed us to fix our problem, I believe... Only comment I have

Re: HTTPCLIENT-1350

only. Karl On Tue, May 7, 2013 at 8:35 AM, Oleg Kalnichevski ol...@apache.org wrote: On Tue, 2013-05-07 at 08:30 -0400, Karl Wright wrote: By default, I'd make it the same as the socket timeout. Makes sense, no? Socket timeout is indefinite (zero) by default. We could pick the greater

Re: Gradle for HC builds

Can you elaborate as to what you feel are the advantages of gradle? Why do you want to switch over? Karl On Thu, Jun 6, 2013 at 8:49 AM, Gary Gregory garydgreg...@gmail.com wrote: Maintaining one build is bad enough. I think I has to be switch and forget otherwise both will have to be

RE: [jira] [Updated] (HTTPCLIENT-1381) NullPointerException during NTLM authentication using null workstation/domain

It is unlikely that messages are improperly encoded in ntlm handling since they were compared directly in wireshark against modern Microsoft products. So I would hesitate to include anything like that in a commit. Karl Sent from my Windows Phone From: Ricardo Pereira (JIRA) Sent: 7/6/2013 9:51

Re: Draft board report for August 2013

Hi, My understanding is that the board also wants the date and ID of last new committer added to the project. Karl On Wed, Aug 7, 2013 at 11:48 PM, Asankha C. Perera asan...@apache.orgwrote: Hi All Its again the time for our report to the board. Could you review the draft I've put

Re: [VOTE] HttpComponents Client 4.2.6 release

Passed all MCF tests. +1 from me. Karl On Sun, Sep 1, 2013 at 6:52 AM, Oleg Kalnichevski ol...@apache.org wrote: Please vote on releasing these packages as HttpComponents Client 4.2.6. The vote is open for the at least 72 hours, and only votes from HttpComponents PMC members are binding.

Re: [VOTE] HttpComponents Client 4.2.6 release

Agreed. The vote is about whether to release the source bits. EOL-style considerations between SVN and the source release really do not apply here. It's a nice-to-have, not a make-or-break. Karl On Mon, Sep 2, 2013 at 1:28 PM, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2013-09-02

Re: [VOTE] HttpComponents Client 4.2.6 release

Hi Sebb, It is essential that the files in a source release can be matched against those in SVN. I think that's technically not necessary according to Apache rules; what's necessary is that the bits in the tar or zip be based *solely* on the svn tag and upstream dependencies. But you really

Re: [VOTE] HttpComponents Client 4.2.6 release based on RC2

Ran all ManifoldCF tests. +1 from me. Karl On Thu, Sep 5, 2013 at 4:19 AM, Oleg Kalnichevski ol...@apache.org wrote: Please vote on releasing these packages as HttpComponents Client 4.2.6. The vote is open for the at least 72 hours, and only votes from HttpComponents PMC members are

Has anyone pushed the 4.2.6 release to maven yet?

If so, it isn't showing up... Karl

Re: Has anyone pushed the 4.2.6 release to maven yet?

Hmm, ok, looks like a proxy caching problem on my end. Thanks for verifying. Karl On Mon, Sep 16, 2013 at 9:34 AM, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2013-09-16 at 09:24 -0400, Karl Wright wrote: If so, it isn't showing up... Karl Hmm. Looks all kosher to me. http

Re: [POLL] Switch to Git?

My vote probably doesn't count -- but a lot of folks have difficulty with git. For example, since git does not manage directories, usually there are issues in porting projects having to do with directories either hanging around and/or not existing in git when they are expected to be present. svn

Re: [POLL] Switch to Git?

clarity on all of these, as much as possible. So, -1 for now (although I could be convinced with some research). Karl On Mon, Feb 3, 2014 at 3:57 AM, Oleg Kalnichevski ol...@apache.org wrote: On Sun, 2014-02-02 at 17:12 -0500, Karl Wright wrote: My vote probably doesn't count -- but a lot

4.3 equivalents of expect-continue parameters

Hi Oleg, I have 4.2 code which does this: params.setBooleanParameter(CoreProtocolPNames.USE_EXPECT_CONTINUE,true); params.setIntParameter(CoreProtocolPNames.WAIT_FOR_CONTINUE,socketTimeout); The 4.3 equivalent uses the request configuration object to set the first, but it's not clear how you

More 4.2-4.3 conversion questions

Hi Oleg, I'm looking for equivalents to these 4.2.x code snippets in 4.3.x: params.setParameter(ClientPNames.DEFAULT_HOST,fetchHost); HttpClientParams.setCookiePolicy(params,CookiePolicy.BROWSER_COMPATIBILITY); localHttpClient.getCookieSpecs().register(CookiePolicy.BROWSER_COMPATIBILITY, new

Porting methodology for maximum backwards compatibility

Hi Oleg, I've been running into significant difficulties porting ManifoldCF's various connectors to the new HttpClient 4.3.x paradigms. Basically, when I do what I think would be the natural port, I wind up currently with connections that often don't work. Since MCF is a bit special in that we

Re: Porting methodology for maximum backwards compatibility

, Karl Wright daddy...@gmail.com wrote: Hi Oleg, I've been running into significant difficulties porting ManifoldCF's various connectors to the new HttpClient 4.3.x paradigms. Basically, when I do what I think would be the natural port, I wind up currently with connections that often don't work

Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA

Hi Malcolm, The right way to contribute a patch is to attach an svn diff to a ticket as a file. The original ticket has already been included in 4.4, so the proper way to do this is to create a new ticket, and attach the patch to it. Thanks, Karl On Fri, Mar 28, 2014 at 6:58 AM, Malcolm

Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA

I go about creating a ticket? Can you point me at some documentation? Thanks, Malcolm. -Original Message- From: Karl Wright [mailto:daddy...@gmail.com] Sent: 28 March 2014 11:49 To: HttpComponents Project Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM

Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA

Message- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: 28 March 2014 13:12 To: HttpComponents Project Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA On Fri, 2014-03-28 at 08:58 -0400, Karl Wright wrote: Hi Malcolm, To create a patch

Expect-continue doesn't seem operative using 4.3.x builder structures

Hi Oleg, A few months back, if you will recall, I ported much of ManifoldCF to use the HttpClient 4.3 builder structures for its various connectors. Unfortunately, one thing we'd previously fixed came unfixed when I did this. We have a user who has a site that is being posted to that requires

Re: Expect-continue doesn't seem operative using 4.3.x builder structures

FWIW, a better way for this kind of thing to be done would be for the request object to have a method, e.g. supportsExpectContinue(), that you would call, instead of relying on class names and hierarchy ... Karl On Thu, May 22, 2014 at 7:10 AM, Karl Wright daddy...@gmail.com wrote: Hi Oleg

Re: Expect-continue doesn't seem operative using 4.3.x builder structures

requests. Or (much better) you could have all HttpRequest objects have a supportExpectContinue method, which in the wrapper would wind up calling the embedded request's supportExpectContinue method. Seems much better, no? Karl On Thu, May 22, 2014 at 8:23 AM, Karl Wright daddy...@gmail.com wrote

Re: Expect-continue doesn't seem operative using 4.3.x builder structures

I've created HTTPCLIENT-1510 to summarize the problem and propose the outlines of a solution. Karl On Thu, May 22, 2014 at 8:27 AM, Karl Wright daddy...@gmail.com wrote: Let me clarify. Right now, you've a wrapper hierarchy that is totally distinct from the original request hierarchy. You

Re: Expect-continue doesn't seem operative using 4.3.x builder structures

Kalnichevski ol...@apache.org wrote: On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote: Hi Oleg, We *are* using POST - multipart post. And this apparently extends HttpRequestWrapper. Which is why expect/continue is not working for us. Why? What for? Even if you are absolutely certain

Re: Expect-continue doesn't seem operative using 4.3.x builder structures

repeated debugging sessions, via patched diagnostic jars, with clients half a world away. Better to fail immediately than give the impression that things were okay when they were not. Thoughts? Karl On Thu, May 22, 2014 at 9:05 AM, Karl Wright daddy...@gmail.com wrote: Hi Oleg

Re: Expect-continue doesn't seem operative using 4.3.x builder structures

: On Thu, 2014-05-22 at 18:16 -0400, Karl Wright wrote: The resolution to this problem was simple -- after I audited both HttpClient and SolrJ code. (0) Expect/continue handling, in the POST-case I was looking at, was in fact *off*. It was disguised by the fact that the thread ID differed

Re: HttpCore trunk is now 5.0

Hi Oleg, Will there be a 4.x release that will deal with RFC 7230? I am wondering why you propose breaking backwards compatibility at the same time you propose adding major new functionality. I've looked at the RFC and don't offhand see any reason why this should be related. We've just gone

Re: HttpCore trunk is now 5.0

is thus always cross-version, until we explicitly stop supporting older major versions. Karl On Tue, Oct 21, 2014 at 9:37 AM, Oleg Kalnichevski ol...@apache.org wrote: On Tue, 2014-10-21 at 08:51 -0400, Karl Wright wrote: Hi Oleg, Will there be a 4.x release that will deal with RFC 7230

Re: My introduction and JIRA karma

the ticket's expiration is (so that we can reticket as needed). Please let me know if I am missing something here. Karl On Fri, Nov 14, 2014 at 1:06 PM, Michael Osipov micha...@apache.org wrote: Am 2014-11-14 um 18:53 schrieb Karl Wright: Hi Michael, [...] Native code is not something

Re: My introduction and JIRA karma

around this in HttpClient? Thanks! Karl On Fri, Nov 14, 2014 at 1:38 PM, Michael Osipov micha...@apache.org wrote: Am 2014-11-14 um 19:21 schrieb Karl Wright: bq. Obtaining a TGT from within Java with a UPN and a password is a snap and can be done with a few line of code. After that, you have

Re: My introduction and JIRA karma

, Michael Osipov micha...@apache.org wrote: Am 2014-11-14 um 20:00 schrieb Karl Wright: bq. Unfortunately, HTTPClient does not support direct use of GSSCredential and always assumes implicit credential. Fortunately, there are several ways to solve that problem too. Is this something you'd

Status of Kerberos auth?

Hi folks, I saw the latest httpclient release go out the door. It was not clear, though, whether Kerberos integration had been completed in the manner planned, using the same credential setup other authentication methods currently use. Can someone fill me in on where things stand? Karl

Re: SSL socket timeouts with SolrJ usage of HttpClient

for setStaleConnectionCheckEnabled(true). It looks like this is now a connection parameter too? Will all of my setStaleConnectionCheckEnabled(true) calls now be invalid? Karl On Thu, Apr 9, 2015 at 3:03 PM, Oleg Kalnichevski ol...@apache.org wrote: On Thu, 2015-04-09 at 10:41 -0400, Karl Wright wrote: Hi Oleg, I've

Redirection not happening?

Hi folks, The ManifoldCF SharePoint connector has the following code to set up its HttpClient instance: >> RequestConfig.Builder requestBuilder = RequestConfig.custom() .setCircularRedirectsAllowed(true) .setSocketTimeout(socketTimeout)

Re: Redirection not happening?

Oh, FWIW, this is httpcomponents/httpclient 4.4.1. Karl On Tue, Feb 16, 2016 at 4:58 PM, Karl Wright <daddy...@gmail.com> wrote: > Hi folks, > > The ManifoldCF SharePoint connector has the following code to set up its > HttpClient instance: > > >>>

Re: Redirection not happening?

Thanks; this is indeed a POST. Karl On Wed, Feb 17, 2016 at 9:04 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Tue, 2016-02-16 at 17:03 -0500, Karl Wright wrote: > > Oh, FWIW, this is httpcomponents/httpclient 4.4.1. > > Karl > > > > > >

Re: New features / new APIs in patch releases (x.y.Z)

I have a sense as to what is driving this, of course, but here are some principles that we use in ManifoldCF: (1) It's always a tradeoff between the severity of the issue and the frequency of releases; if the Next Minor Release is due in a month, then there's a high bar for adding features or API

Re: svn commit: r1787500 - /httpcomponents/httpclient/branches/4.5.x/httpclient/src/main/java/org/apache/http/impl/auth/CredSspScheme.java

Done. Karl On Sat, Mar 18, 2017 at 6:28 AM, Gary Gregory wrote: > It might be better to have a constant for new byte[0] > > Gary > > -- Forwarded message -- > From: > Date: Fri, Mar 17, 2017 at 10:06 PM > Subject: svn commit:

Construction of Content Disposition header in multipart forms

Hi Oleg et al, ManifoldCF is having an issue with some repositories that use filenames that contain spaces and quotes. Specifically, when we send this data as a multipart form to Solr, it doesn't get properly interpreted. I've chased this down to the filename addendum of the Content Disposition

Re: Construction of Content Disposition header in multipart forms

to; if not, please give the magical command line git command to set myself up with the httpclient repository so I can code a fix. Thanks, Karl On Wed, Jun 21, 2017 at 9:59 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Wed, 2017-06-21 at 06:38 -0400, Karl Wright wrote: > >

Re: Valid usecase of CredSSP auth scheme

Hi Michael, I did not contribute this work; I merely obliquely helped integrating it. If I recall correctly, there was a reasonable case made for it, but I don't remember what it wasy. Karl On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov wrote: > Guys, > > I just have discovered that CredSSP

Pre-emptive authorization

Hi Oleg et al, One ManifoldCF user has an unusual requirement for basic auth that requires the auth header to be sent pre-emptively, not as a consequence of receiving a 401 response. He proposes the following patch for ManifoldCF, but I wonder whether there's a better way to do this with

Re: Pre-emptive authorization

? Karl On Thu, Jan 3, 2019 at 12:21 PM Michael Osipov wrote: > Am 2019-01-03 um 17:33 schrieb Karl Wright: > > Hi Oleg et al, > > > > One ManifoldCF user has an unusual requirement for basic auth that > requires > > the auth header to be sent pre-emptively, not a

Re: Gradual deprecation and removal of NTLM and SPNEGO support

These protocols are, unfortunately, still used. However, the projects I know that use them have not yet moved to 5.x of httpcomponents. Other projects I know of that used to use httpcomponents have since upgraded to different http libraries that supported http 2.0 early on. The hint that all it

Re: Gradual deprecation and removal of NTLM and SPNEGO support

This is not a security issue. The implementation of NTLM is just as secure as the Microsoft implementation. That's not terribly secure but that's inherent in their design. Karl On Sat, Nov 20, 2021 at 7:02 PM larry mccay wrote: > This is a concerning statement and I need some additional

[jira] Created: (HTTPCLIENT-917) When authentication is invalidated during redirection, proxy authentication also should be invalidated

/browse/HTTPCLIENT-917 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Reporter: Karl Wright This was discovered during use by Lucene Connector Framework, on 3.1. When a document is fetched through a proxy authenticated

[jira] Updated: (HTTPCLIENT-917) When authentication is invalidated during redirection, proxy authentication also should be invalidated

[ https://issues.apache.org/jira/browse/HTTPCLIENT-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated HTTPCLIENT-917: --- Attachment: proxy-auth-invalidate.patch When authentication is invalidated during

[jira] Created: (HTTPCLIENT-918) Redirection or multi-stage authentication (such as NTLM) currently make it impossible to use HttpClient with a non-default protocol factory

--- Key: HTTPCLIENT-918 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-918 Project: HttpComponents HttpClient Issue Type: Improvement Reporter: Karl Wright This was discovered during development of Lucene Connector Framework. When HttpClient

  1   2   3   4   >