My english is poor, but I tried to describe the problem as much clear as possible.
I try to make GET request using HttpClient from Apache Http Client.
Every time I try to do it using Apache Http Client, remote server redirects me with "301 Moved Permanently". Redirection doesn't occur when I use URLConnection or curl (through command line or php).
I guess that there are some predefined settings in Apache Http Client that cause remote server to redirect me.
I get this error:
Code that doesn't work:
None of the solutions from the internet works.
But when I use plain URLConnection then it works and no redirection occurs.
Code that works:
What is wrong with Apache Http Client?
By the way, using curl in php it also works fine without any redirection:
A HTTP 301 - Moved Permanently response is very common and while it can be used manually to indicate an actual re-located web page, it seems to be a common routing mechanism in normal configurations as well.
Some clients will recognize the Location given in the 301 response and re-issue the request, making it look like the request went straight through. Other clients, however, will dead-end.
The curl utility can be told to do either of the above, given the right command-line options.
Incidentally, while I'm not 100% sure, I think that "301" is used in JavaServer Faces to enforce security. Since container-managed security is based on the incoming HTTP URL and normal JSF operation uses the URL as a handle, and not as an absolute page locator, you have to use the JSF REDIRECT option to re-route to the protected URL and thereby ensure that the underlying resource has the proper access rules applied. And JSF REDIRECT is - I'm reasonably certain - done by returning an HTTP 301. It's extra overhead, but beats having your payroll data end up for sale on the Internet.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
David Belcher wrote:Every time I try to do it using Apache Http Client, remote server redirects me with "301 Moved Permanently"
I noticed that if you try to establish an http connection, rather than an https, that it will behave as you describe - trying to upgrade the security of the connection. Is it possible that something in your connection path might be rewriting the URL to use http?
When I run your code as-is (with httpclient version 4.5.6), it works as expected, and I see the following output:
Here is the logging:
These are the properties I used to enable the logging: