[jira] [Closed] (NET-635) Problems with German summertime
[ https://issues.apache.org/jira/browse/NET-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Naber closed NET-635. --- Resolution: Fixed It's no bug. You have to use the setServerTimeZoneId function, in order to the server AND Client calculate the timestamps in the same timezone. > Problems with German summertime > --- > > Key: NET-635 > URL: https://issues.apache.org/jira/browse/NET-635 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: linux >Reporter: Peter Naber >Priority: Minor > > There is a problem at the funktion > org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp > At the ftp Server exists a file with the timestamp "Mar 26 02:29" > In Germany, the clock will be switched at 2:00 from wintertime to summertime > Mar 26 2:00 -> Mar 26 3:00. > So the time "Mar 26 02:29" is invalid if the commons-net function will run on > a german server. > The workaround is, to set the servertimezone to GMT -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NET-635) Problems with German summertime
[ https://issues.apache.org/jira/browse/NET-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943774#comment-15943774 ] Peter Naber commented on NET-635: - I think you are right with your arguments. If the ftp Server works with GMT timezone, the time 26 March 2:29 is OK, for the client with CET it's an invalid time. So it is absolute necessary to use the setServerTimeZoneId function if you will not have invalid times by the switch summer/winter Time. > Problems with German summertime > --- > > Key: NET-635 > URL: https://issues.apache.org/jira/browse/NET-635 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: linux >Reporter: Peter Naber >Priority: Minor > > There is a problem at the funktion > org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp > At the ftp Server exists a file with the timestamp "Mar 26 02:29" > In Germany, the clock will be switched at 2:00 from wintertime to summertime > Mar 26 2:00 -> Mar 26 3:00. > So the time "Mar 26 02:29" is invalid if the commons-net function will run on > a german server. > The workaround is, to set the servertimezone to GMT -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NET-635) Problems with German summertime
Peter Naber created NET-635: --- Summary: Problems with German summertime Key: NET-635 URL: https://issues.apache.org/jira/browse/NET-635 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.6 Environment: linux Reporter: Peter Naber Priority: Minor There is a problem at the funktion org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp At the ftp Server exists a file with the timestamp "Mar 26 02:29" In Germany, the clock will be switched at 2:00 from wintertime to summertime Mar 26 2:00 -> Mar 26 3:00. So the time "Mar 26 02:29" is invalid if the commons-net function will run on a german server. The workaround is, to set the servertimezone to GMT -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (NET-480) Wrong passivHost by using FTPHTTPClient with EPSV
[ https://issues.apache.org/jira/browse/NET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454810#comment-13454810 ] Peter Naber edited comment on NET-480 at 9/13/12 10:16 PM: --- Own testet SquidProxy Class with working EPSV Protocol. A new class variable is add : host This variable contain the original destination Address. At _openDataConnection_ the variable __passivHost will set to the destination address. By using PASV the variable is set to "this.getPassiveHost()", by using EPSV to this.host was (Author: triumvir): Own testet SquidProxy Class with working EPSV Protocol > Wrong passivHost by using FTPHTTPClient with EPSV > - > > Key: NET-480 > URL: https://issues.apache.org/jira/browse/NET-480 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.1 > Environment: All Systems with ftp Access over ftp >Reporter: Peter Naber > Attachments: FTPSquidProxyClient.java > > > At the FTPHTTPClient Class in line 99 the Answer from the EPSV Command will > parse to receive the Data port and the passiv Host. > \_parsePassiveModeReply(\_replyLines.get(0)) > In this function the \_\_passivHost is set to the remoteAddress, but this > address is determine by "this.\_socket\_.getInetAddress();" and the socket is > the socket of the proxy Server and NOT of the ftp Server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-480) Wrong passivHost by using FTPHTTPClient with EPSV
[ https://issues.apache.org/jira/browse/NET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Naber updated NET-480: Attachment: FTPSquidProxyClient.java Own testet SquidProxy Class with working EPSV Protocol > Wrong passivHost by using FTPHTTPClient with EPSV > - > > Key: NET-480 > URL: https://issues.apache.org/jira/browse/NET-480 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.1 > Environment: All Systems with ftp Access over ftp >Reporter: Peter Naber > Attachments: FTPSquidProxyClient.java > > > At the FTPHTTPClient Class in line 99 the Answer from the EPSV Command will > parse to receive the Data port and the passiv Host. > \_parsePassiveModeReply(\_replyLines.get(0)) > In this function the \_\_passivHost is set to the remoteAddress, but this > address is determine by "this.\_socket\_.getInetAddress();" and the socket is > the socket of the proxy Server and NOT of the ftp Server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-480) Wrong passivHost by using FTPHTTPClient with EPSV
[ https://issues.apache.org/jira/browse/NET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453822#comment-13453822 ] Peter Naber commented on NET-480: - Oh sorry, it's my mistake. I mean the methode _parseExtendedPassiveModeReply() (EPSV not PASV). No, I haven't a patch for it, only a dirty workaround for me :-) I will look today, if I found a clean solution for it. > Wrong passivHost by using FTPHTTPClient with EPSV > - > > Key: NET-480 > URL: https://issues.apache.org/jira/browse/NET-480 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.1 > Environment: All Systems with ftp Access over ftp >Reporter: Peter Naber > > At the FTPHTTPClient Class in line 99 the Answer from the EPSV Command will > parse to receive the Data port and the passiv Host. > \_parsePassiveModeReply(\_replyLines.get(0)) > In this function the \_\_passivHost is set to the remoteAddress, but this > address is determine by "this.\_socket\_.getInetAddress();" and the socket is > the socket of the proxy Server and NOT of the ftp Server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-480) Wrong passivHost by using FTPHTTPClient with EPSV
Peter Naber created NET-480: --- Summary: Wrong passivHost by using FTPHTTPClient with EPSV Key: NET-480 URL: https://issues.apache.org/jira/browse/NET-480 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1 Environment: All Systems with ftp Access over ftp Reporter: Peter Naber At the FTPHTTPClient Class in line 99 the Answer from the EPSV Command will parse to receive the Data port and the passiv Host. _parsePassiveModeReply(_replyLines.get(0)) In this function the __passivHost is set to the remoteAddress, but this address is determine by "this._socket_.getInetAddress();" and the socket is the socket of the proxy Server and NOT of the ftp Server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
