Re: 400 bad request POSTing to Tomcat 7.0.42
You didn't optimise as we suggested in the end, you're still building the content up in memory. As suggested by a few, write to a stream so nothing needs to consume your clients memory and will scale better Sent from my iPhone On 3 Mar 2015, at 22:06, Alessandro Manzoni manzoni.alessand...@gmail.com wrote: Il 03.03.2015 09.47, Alexey Panchenko ha scritto: I am curious about how the client code looks now, before we continue complaining on the other end. Just trying to be fair. 1 HttpClient httpclient = new DefaultHttpClient(); 2 HttpPost httppost = new HttpPost(uri); 3 httppost.addHeader(Content-Type, text/xml;charset=utf-8); 4 ByteArrayEntity entity = new ByteArrayEntity(output.toByteArray()); 5 // StringEntity entity = new StringEntity(new String(output.toByteArray()), ContentType.TEXT_XML); 6 httppost.setEntity(entity); 7 HttpResponse response = httpclient.execute(httppost); That's it. Added line 3 and line 4 replaced line 5. On Tue, Mar 3, 2015 at 2:36 PM, Brett Ryan brett.r...@gmail.com wrote: What confused me, is that I thought that tomcat should honor the encoding set inside xml, while it just use content-type encoding or its default one instead. Thats the correct behaviour. Your servlet container may choose to inspect the POST data but there is no requirement for it to, thats up to you to implement a filter as mentioned earlier. What if your XML was malformed, what do you think it should do? The content could be anything for all it cares. What would your processor do if the header of the XML said the encoding was 8859-1, but the actual encoding was UCS-2? You wouldn't even be able to read the header reliably, you would have to perform a series of rereads to get the right encoding. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: 400 bad request POSTing to Tomcat 7.0.42
Since I produce the xml in memory, that's the way Marshal.marshal method works, I could use the ByteArrayEntity using the byte[] from the ByteArrayOutputStream supplied to marshal. Could you not do something like PipedOutputStream out = new PipedOutputStream(); InputStream instr = new PipedInputStream(out); marshaller.marshal(object, out); HttpPost post = new HttpPost(); post.setEntity(new InputStreamEntity(instr)); I have t validated this as I'm just on my phone but thats where id start. Always try to write to a stream wherever possible instead of building up in memory only to dump it out. But docs tell me that ByteArrayEntity is not thread-safe, while I need to use HttpClient by conncurrent threads. You would be only creating the entity per request, so thread safety is not an issue. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: 400 bad request POSTing to Tomcat 7.0.42
On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote:
Since I produce the xml in memory, that's the way Marshal.marshal method
works, I could use the ByteArrayEntity using the byte[] from the
ByteArrayOutputStream supplied to marshal.
Could you not do something like
PipedOutputStream out = new PipedOutputStream();
InputStream instr = new PipedInputStream(out);
marshaller.marshal(object, out);
HttpPost post = new HttpPost();
post.setEntity(new InputStreamEntity(instr));
A custom HttpEntity implementation that internally makes use of JAXB
marshaling would be massively more efficient.
Oleg
Ok, now you're being mean, j/k ;)
Something like (I'm still on the train so this is probably totally wrong)
post.setEntity(new HttpEntity() {
void write(OutputStream out) {
marshaller.marshal(object, out);
}
// implement other methods too...
});
Half guessing, but where id start to look.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Support for http 2.0
Tony, HTTP/2 is 1.1 backwards compatible. If the client doesn't understand HTTP/2 then it will not elect HTTP/2 features. From my understanding performance gains are only going to be noticed by the new push mechanism that allows the server serve up parts of the content that the server thinks the client needs to render the response. While a client may understand HTTP/2, the server needs to also, AND so does the application running on the server so that the application can manifest what content should be served up with the main request. With all this, considering that there's only a select few of servers supporting HTTP/2, I think the HC project has a little time before HTTP/2 support is going to be something a lot of developers are requiring. On 25 Feb 2015, at 11:43, Tony Anecito adanec...@yahoo.com.INVALID wrote: Good question. Simpler means no frameworks without all the features and focus on simple url type calls to take advantage of the performance to begin with.http 2.0 is mostly about performance. The question is what will be available this month and beginning next month and who will be early adopters.The amount of money saved for big sites is quite a bit. And network and app server folks will love it. Regards,-Tony On Tuesday, February 24, 2015 4:10 PM, Stefan Magnus Landrø stefan.lan...@gmail.com wrote: What do you mean by simpler? Sendt fra min iPhone Den 24. feb. 2015 kl. 20.46 skrev Tony Anecito adanec...@yahoo.com.INVALID: My guess is IT and developers will be pushed to quickly use the new standard and bypass HC to use a simpler solution in the interim. Regards,-Tony On Tuesday, February 24, 2015 12:39 PM, Tony Anecito adanec...@yahoo.com.INVALID wrote: Thanks Gary looks like discussions are happening but nothing is ever vary fast. -Tony On Tuesday, February 24, 2015 12:08 PM, Gary Gregory garydgreg...@gmail.com wrote: Please see https://marc.info/?l=httpclient-commons-devm=142434644830689w=2 Gary On Tue, Feb 24, 2015 at 10:56 AM, Tony Anecito adanec...@yahoo.com.invalid wrote: Hi All, Is there plans by Apache http components to support http 2.0? Thanks,-Tony -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: how to disable cookie in HttpComponents Client?
Put it back in the jar? ;) Sent from my iPad On 18 Jul 2014, at 7:41 pm, Li Li fancye...@gmail.com wrote: I don't want to keep cookie. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Using basic auth produces warnings about NTLM and NEGOTIATE errors.
Any other way to prevent it? I've also tried setting the proxyPreferredAuthSchemes property with no change. On 12 February 2014 02:44, Oleg Kalnichevski ol...@apache.org wrote: On Wed, 2014-02-12 at 02:21 +1100, Brett Ryan wrote: Thanks Oleg, I've added this to the client, yet I am still getting the same warnings. LookupAuthSchemeProvider authProviders = RegistryBuilder.AuthSchemeProvidercreate() .register(AuthSchemes.BASIC, new BasicSchemeFactory()) .build(); RequestConfig rc = RequestConfig.custom() .setTargetPreferredAuthSchemes(Arrays.asList(BASIC)) .build(); BasicCredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials(AuthScope.ANY, null); client = HttpClients.custom() .setDefaultCredentialsProvider(credsProvider) .setDefaultAuthSchemeRegistry(authProviders) .setDefaultRequestConfig(rc) .setTargetAuthenticationStrategy(TargetAuthenticationStrategy.INSTANCE) .build(); Can happen if the proxy auth strategy tries to pick up an auth scheme from the list of preferred schemes still containing NTLM and SPNEGO. Oleg On 12 February 2014 00:58, Oleg Kalnichevski ol...@apache.org wrote: On Tue, 2014-02-11 at 14:20 +1100, Brett Ryan wrote: If a server supports NTLM and Kerberos authentication, but when setting up the client I only provide basic credentials I get a log for each of the NTLM and NEGOTIATE authentication schemes. Taking the example from : https://hc.apache.org/httpcomponents-client-4.3.x/httpclient/examples/org/apache/http/examples/client/ClientAuthentication.java CredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials( new AuthScope(null, -1), new UsernamePasswordCredentials(restUser, restPass)); CloseableHttpClient client = HttpClients.custom() .setDefaultCredentialsProvider(credsProvider) .build(); Use of the above client will produce the following warnings, though requests succeed fine through basic authentication: WARN o.a.http.impl.auth.HttpAuthenticator - NEGOTIATE authentication error: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm) WARN o.a.http.impl.auth.HttpAuthenticator - NTLM authentication error: Credentials cannot be used for NTLM authentication: org.apache.http.auth.UsernamePasswordCredentials So I figured after searching through the builder method that I'd supply an auth provider with only basic support: LookupAuthSchemeProvider authProviders = RegistryBuilder.AuthSchemeProvidercreate() .register(AuthSchemes.BASIC, new BasicSchemeFactory()) .build(); CloseableHttpClient client = HttpClients.custom() .setDefaultCredentialsProvider(credsProvider) .setDefaultAuthSchemeRegistry(authProviders) .build(); But now I get a different warning about the scheme's no longer being enabled. WARN o.a.h.i.c.TargetAuthenticationStrategy - Authentication scheme negotiate not supported WARN o.a.h.i.c.TargetAuthenticationStrategy - Authentication scheme NTLM not supported How do I simply get rid of these warnings and only get the client to use the basic scheme that I've configured? --- RequestConfig config = RequestConfig.custom() .setTargetPreferredAuthSchemes(Arrays.asList(BASIC)) .build(); HttpGet get = new HttpGet(/); get.setConfig(config); --- Hope this helps Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Using basic auth produces warnings about NTLM and NEGOTIATE errors.
If a server supports NTLM and Kerberos authentication, but when setting up the client I only provide basic credentials I get a log for each of the NTLM and NEGOTIATE authentication schemes. Taking the example from : https://hc.apache.org/httpcomponents-client-4.3.x/httpclient/examples/org/apache/http/examples/client/ClientAuthentication.java CredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials( new AuthScope(null, -1), new UsernamePasswordCredentials(restUser, restPass)); CloseableHttpClient client = HttpClients.custom() .setDefaultCredentialsProvider(credsProvider) .build(); Use of the above client will produce the following warnings, though requests succeed fine through basic authentication: WARN o.a.http.impl.auth.HttpAuthenticator - NEGOTIATE authentication error: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm) WARN o.a.http.impl.auth.HttpAuthenticator - NTLM authentication error: Credentials cannot be used for NTLM authentication: org.apache.http.auth.UsernamePasswordCredentials So I figured after searching through the builder method that I'd supply an auth provider with only basic support: LookupAuthSchemeProvider authProviders = RegistryBuilder.AuthSchemeProvidercreate() .register(AuthSchemes.BASIC, new BasicSchemeFactory()) .build(); CloseableHttpClient client = HttpClients.custom() .setDefaultCredentialsProvider(credsProvider) .setDefaultAuthSchemeRegistry(authProviders) .build(); But now I get a different warning about the scheme's no longer being enabled. WARN o.a.h.i.c.TargetAuthenticationStrategy - Authentication scheme negotiate not supported WARN o.a.h.i.c.TargetAuthenticationStrategy - Authentication scheme NTLM not supported How do I simply get rid of these warnings and only get the client to use the basic scheme that I've configured?
