使用Java进行FTP Put命令通过Squid HTTP代理错误
我对 Java 有点陌生,但在尝试通过 SQUID HTTP 代理将本地文件上传到远程 FTP 服务器时遇到了问题(请注意,这显然束缚了我的手脚,因此“FTP”和“SOCKS”代理类型不在范围内)。
这是我的代码:
URL url = new URL(urlString);
OutputStream os ;
System.setProperty("proxySet", "true");
System.setProperty("proxyHost", proxyHost.trim());
System.setProperty("proxyPort", proxyPort.stringValue());
URLConnection ftpConn = url.openConnection() ;
ftpConn.setAllowUserInteraction(true); //threw this in to see if it would work, does nothing
ftpConn.setDoOutput(true); //here is where I set the setDoOutput
os = ftpConn.getOutputStream(); //here is where the exception occurs
我不断收到此异常:
Java 调用被未捕获的 Java 终止 异常:java.net.ProtocolException: 无法写入 URLConnection,如果 doOutput=false - 调用 setDoOutput(true)
所以我用 FTPURLConnection 等尝试过,并且遇到了同样的问题。
调试此问题时,ftpConn 中似乎有不少于三个名为 doOutput 的变量。
只有一个是可编辑的(而其他两个则不可)
第一个(似乎是通过 getDoOutput 返回的)在设置 < 后返回 true em>ftpConn.setDoOutput(true);。
public synchronized OutputStream getOutputStream()
throws IOException {
try {
if (!doOutput) {
throw new ProtocolException(
"cannot write to a URLConnection"
+ " if doOutput=false - call setDoOutput(true)");
}
查看 FtpURLConnection 让我相信,当它确定您正在使用 HTTP 代理时,它会将处理传递给 HttpURLConnection。
我认为这就是断开连接发生的地方(无论是对我、图书馆还是代理)。
我是否缺少设置 setDoOutput 或其他内容的方法?
我已经能够成功地从代理中隧道出 GET,但 PUT 在 doOutput 上全部失败。
感谢您提供任何帮助或指示来使其正常工作。
聚苯乙烯 我使用的是 Java 1.5.0_10(我们在这里是为了与其他应用程序保持一致)
I am a bit green with Java but I have ran into an issue when trying to UPLOAD a local file to a remote FTP server through a SQUID HTTP proxy (please note this obviously ties my hands so that 'FTP' and 'SOCKS' proxy types are not in scope).
So here is my code:
URL url = new URL(urlString);
OutputStream os ;
System.setProperty("proxySet", "true");
System.setProperty("proxyHost", proxyHost.trim());
System.setProperty("proxyPort", proxyPort.stringValue());
URLConnection ftpConn = url.openConnection() ;
ftpConn.setAllowUserInteraction(true); //threw this in to see if it would work, does nothing
ftpConn.setDoOutput(true); //here is where I set the setDoOutput
os = ftpConn.getOutputStream(); //here is where the exception occurs
I keep getting this exception:
Java call terminated by uncaught Java
exception: java.net.ProtocolException:
cannot write to a URLConnection if
doOutput=false - call
setDoOutput(true)
So I have tried this with an FTPURLConnection etc and have had the same issue.
When debugging this, it appears that there are no less than THREE variables that are called doOutput within the ftpConn.
Only one is editable (whereas the other two are not)
The first one (and it seems the one that is returned via the getDoOutput) returns true after the setting of the ftpConn.setDoOutput(true);.
looking over the source code for HttpURLConnection:
public synchronized OutputStream getOutputStream()
throws IOException {
try {
if (!doOutput) {
throw new ProtocolException(
"cannot write to a URLConnection"
+ " if doOutput=false - call setDoOutput(true)");
}
Looking over the Proxy handling in FtpURLConnection leads me to believe that when it determines that you are using an HTTP Proxy it passes off the the processing to the HttpURLConnection.
This is where I think the disconnect is happening (either for me or the library or the proxy).
Am I missing someway to set the setDoOutput or something else?
I have been able to successfully tunnel out of the proxy for GETs, but PUTs are all FAILING on the doOutput.
Thanks for any help or pointers to get this to work.
P.S.
I am using Java 1.5.0_10 (we are here to remain consistent with other applications)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
很好地发现这是metalink中的一个错误(错误6519647)。解决方法几乎是使用不同的东西!
(无论代理如何设置(带/不带“http”,甚至通过代理类),此错误仍然存在。
对于重复的编辑/答案,这是我对自己问题的第一个“答案”。
切换了ftp4j 但仍然遇到鱿鱼代理问题(这是一个完全不同的故事)。
well found out this is a bug (Bug 6519647) in metalink. the workaround is pretty much use something different!
(this bug persists no matter how the proxy is set (with/wihtout the "http." and even via the proxy class)
sorry for the duplicate edit/answer, this is my first 'answer' to my own question.
switched over the ftp4j but still running into squid proxy issues (which is a whole different story).