[
https://issues.apache.org/jira/browse/FTPSERVER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomislav Haramustek updated FTPSERVER-488:
------------------------------------------
Description:
The problem is when a FTP client sets the file offset with REST command not
immediatelly followed by RETR command.
When REST is received the offset is put in the attributes map with appropriate
key and everything seems to be fine. Even the implementation of RETR command
takes that file offset into account and everything works according to
excpectations if there is no other command received in the meantime, i.e. if
REST is immediatelly followed by RETR (for the same session). But, there are
some clients that do not conform to that (although RFC959 specifies that REST
should be immediatelly followed by a command that will trigger data transfer),
but send some other command instead, e.g. PASV. The implementation of PASV
command resets the session state and the offset efectivelly becomes 0.
I don't know if this can be treated as a bug since the actual implementation
follows RFC specification, but I wanted to share this with everybody and to get
some suggestions what to do in such cases.
I have overcome the issue in my specific use case by reimplementing PASV
command and not to clear the session, i.e. to leave file offset attribute
intact, but I am not sure if that will have some problematic effects in general
use case despite the fact that call to resetState actually clears just rename
and offset attributes.
was:
The problem is when a FTP client sets the file offset with REST command not
immediatelly followed by RETR command.
When REST is received the offset is put in the attributes map with appropriate
key and everything seems to be fine. Even the implementation of RETR command
takes that file offset into account and everything works according to
excpectations if there is no other command received in the meantime, i.e. if
REST is immediatelly followed by RETR (for the same session). But, there are
some clients that do not conform to that (although RFC959 specifies that REST
should be immediatelly followed by a command that will trigger data transfer),
but send some other command instead, e.g. PASV. The implementation of PASV
command resets the session state and the offset efectivelly becomes 0.
I don't know if this can be treated as a bug since the actual implementation
follows RFC specification, but I wanted to share this with everybody and to get
some suggestions what to do in such cases.
> File offset cleared before data transfer requested
> --------------------------------------------------
>
> Key: FTPSERVER-488
> URL: https://issues.apache.org/jira/browse/FTPSERVER-488
> Project: FtpServer
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.1.1
> Reporter: Tomislav Haramustek
> Priority: Major
>
> The problem is when a FTP client sets the file offset with REST command not
> immediatelly followed by RETR command.
> When REST is received the offset is put in the attributes map with
> appropriate key and everything seems to be fine. Even the implementation of
> RETR command takes that file offset into account and everything works
> according to excpectations if there is no other command received in the
> meantime, i.e. if REST is immediatelly followed by RETR (for the same
> session). But, there are some clients that do not conform to that (although
> RFC959 specifies that REST should be immediatelly followed by a command that
> will trigger data transfer), but send some other command instead, e.g. PASV.
> The implementation of PASV command resets the session state and the offset
> efectivelly becomes 0.
> I don't know if this can be treated as a bug since the actual implementation
> follows RFC specification, but I wanted to share this with everybody and to
> get some suggestions what to do in such cases.
> I have overcome the issue in my specific use case by reimplementing PASV
> command and not to clear the session, i.e. to leave file offset attribute
> intact, but I am not sure if that will have some problematic effects in
> general use case despite the fact that call to resetState actually clears
> just rename and offset attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
