[jira] [Commented] (NET-577) Fails to parse FEAT response from Gene6 FTP server
[
https://issues.apache.org/jira/browse/NET-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620284#comment-14620284
]
Jochen Kemnade commented on NET-577:
It's a Gene6 FTP server 3.9.0 (Build 2) (www.g6ftpserver.com). I haven't
checked whether the current version also behaves like that. And yes, the
behavior is wrong according to the RFC.
> Fails to parse FEAT response from Gene6 FTP server
> --
>
> Key: NET-577
> URL: https://issues.apache.org/jira/browse/NET-577
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
>Reporter: Jochen Kemnade
>
> This is probably rather a bug in the server implementation, but anyway.
> The response from a Microsoft FTP Service I'm trying to work with looks like
> that:
> {noformat}
> 211-FEAT
> SIZE
> MDTM
> 211 END
> {noformat}
> So, after parsing the response, the entries in the features map are {{
> SIZE}} and {{ MDTM}}.
> While it doesn't adhere to the RFC (there's supposed to be a single leading
> space for each feature), it should be possible to work around that kind of
> broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NET-577) Fails to parse FEAT response from Gene6 FTP server
[
https://issues.apache.org/jira/browse/NET-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated NET-577:
---
Summary: Fails to parse FEAT response from Gene6 FTP server (was: Fails to
parse FEAT response from Microsoft FTP Service)
> Fails to parse FEAT response from Gene6 FTP server
> --
>
> Key: NET-577
> URL: https://issues.apache.org/jira/browse/NET-577
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
>Reporter: Jochen Kemnade
>
> This is probably rather a bug in the server implementation, but anyway.
> The response from a Microsoft FTP Service I'm trying to work with looks like
> that:
> {noformat}
> 211-FEAT
> SIZE
> MDTM
> 211 END
> {noformat}
> So, after parsing the response, the entries in the features map are {{
> SIZE}} and {{ MDTM}}.
> While it doesn't adhere to the RFC (there's supposed to be a single leading
> space for each feature), it should be possible to work around that kind of
> broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-558) getModificationTime() returns complete received line including response code
[ https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618247#comment-14618247 ] Jochen Kemnade commented on NET-558: I also get a trailing newline in 3.4-SNAPSHOT. > getModificationTime() returns complete received line including > response code > -- > > Key: NET-558 > URL: https://issues.apache.org/jira/browse/NET-558 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: The ftp server supports MDTM. >Reporter: Ralph Becker >Priority: Minor > Labels: commons-net, ftp > Fix For: 3.4 > > > When retrieving the last modification time of a file on the server via the > method getModificationTime(String filename) it returns something like > "213 2014112706" where only the part after the space is the relevant data. > I digged deeper and i found that the first part before the space is the > positive > response code which is not removed before getModificationTime returns. > I consider this a minor bug as i think there is a simple work around > (split by space, use second part only) but i do not believe that > the result of the method is what a user expects regarding the documentation > of that method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NET-577) Fails to parse FEAT response from Microsoft FTP Service
Jochen Kemnade created NET-577:
--
Summary: Fails to parse FEAT response from Microsoft FTP Service
Key: NET-577
URL: https://issues.apache.org/jira/browse/NET-577
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Reporter: Jochen Kemnade
This is probably rather a bug in the server implementation, but anyway.
The response from a Microsoft FTP Service I'm trying to work with looks like
that:
{noformat}
211-FEAT
SIZE
MDTM
211 END
{noformat}
So, after parsing the response, the entries in the features map are {{ SIZE}}
and {{ MDTM}}.
While it doesn't adhere to the RFC (there's supposed to be a single leading
space for each feature), it should be possible to work around that kind of
broken response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-558) getModificationTime() returns complete received line including response code
[ https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608099#comment-14608099 ] Jochen Kemnade commented on NET-558: If I use the `substring(4)` approach in 3.3 with a WINDOWS ftp server, there's still a trailing newline in the response. Not sure if that'll be an issue in 3.4. > getModificationTime() returns complete received line including > response code > -- > > Key: NET-558 > URL: https://issues.apache.org/jira/browse/NET-558 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: The ftp server supports MDTM. >Reporter: Ralph Becker >Priority: Minor > Labels: commons-net, ftp > Fix For: 3.4 > > > When retrieving the last modification time of a file on the server via the > method getModificationTime(String filename) it returns something like > "213 2014112706" where only the part after the space is the relevant data. > I digged deeper and i found that the first part before the space is the > positive > response code which is not removed before getModificationTime returns. > I consider this a minor bug as i think there is a simple work around > (split by space, use second part only) but i do not believe that > the result of the method is what a user expects regarding the documentation > of that method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (NET-558) getModificationTime() returns complete received line including response code
[
https://issues.apache.org/jira/browse/NET-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608099#comment-14608099
]
Jochen Kemnade edited comment on NET-558 at 6/30/15 10:40 AM:
--
If I use the {{substring(4)}} approach in 3.3 with a WINDOWS ftp server,
there's still a trailing newline in the response. Not sure if that'll be an
issue in 3.4.
was (Author: jkemnade):
If I use the `substring(4)` approach in 3.3 with a WINDOWS ftp server, there's
still a trailing newline in the response. Not sure if that'll be an issue in
3.4.
> getModificationTime() returns complete received line including
> response code
> --
>
> Key: NET-558
> URL: https://issues.apache.org/jira/browse/NET-558
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
> Environment: The ftp server supports MDTM.
>Reporter: Ralph Becker
>Priority: Minor
> Labels: commons-net, ftp
> Fix For: 3.4
>
>
> When retrieving the last modification time of a file on the server via the
> method getModificationTime(String filename) it returns something like
> "213 2014112706" where only the part after the space is the relevant data.
> I digged deeper and i found that the first part before the space is the
> positive
> response code which is not removed before getModificationTime returns.
> I consider this a minor bug as i think there is a simple work around
> (split by space, use second part only) but i do not believe that
> the result of the method is what a user expects regarding the documentation
> of that method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
