FTP upload command syntax error GET instead of PUT

RESOLVED WONTFIX

Status

()

Core
Networking: FTP
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: CADMO, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15
Build ID: 20130105222038

Steps to reproduce:

ftp://myusername:mypassword@myhost.mydoma.in/mydir
- File
-- Upload File
--- browse for file xxx.yyy to upload and select it
---- message windows appears with info on transfer... then it closes



Actual results:

SeaMonkey issue a ftp GET of xxx.yyy


Expected results:

SeaMonkey should issue a ftp PUT of xxx.yyy
(Reporter)

Comment 1

5 years ago
On SM 1.x it was OK.

Comment 2

5 years ago
Current SeaMonkey supported version is 2.16.2 Does this problem still occur in 2.16?

Comment 3

5 years ago
> ---- message windows appears with info on transfer... then it closes

Did xxx.yyy actually get uploaded to the server?

If SeaMonkey issue an ftp GET of xxx.yyy then wouldn't that have downloaded xxx.yyy from the server to your computer?

Comment 4

5 years ago
Working for me on both
User agent: Mozilla/5.0 (Windows NT 5.2; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2
Build identifier: 20130310201055
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19a1
Build identifier: 20130305003008
Invoke upload, file present after page refresh.
Whiteboard: closeme WFM 2013-04-01
(Reporter)

Comment 5

5 years ago
(In reply to therube from comment #3)
> > ---- message windows appears with info on transfer... then it closes
> 
> Did xxx.yyy actually get uploaded to the server?
> 
> If SeaMonkey issue an ftp GET of xxx.yyy then wouldn't that have downloaded
> xxx.yyy from the server to your computer?

No, xxx.yyy was NOT uploaded (via SeaMonkey) on the server.
Well, SeaMonkey issue a ftp GET of xxx.yyy to the ftp server (easy to see, either by snooping the packets or checking a log on the server) and the server acts properly in reply to that (File NOT FOUND) but the reply is NOT managed by SM (if SM believes tu upload, that's right...).
(Reporter)

Comment 6

5 years ago
Tested on SeaMonkey 2.16.2.
SAME ERROR.

Build notes:
User agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2
Identificativo build: 20130310201055 

This is the IT version of SM ("other languages options" from SM web site).

I can not understand WHY Phoenix says it works!
Sounds really strange to me!

Log of ftp server:
Mar 20 16:31:47 6D:XX ftpd[43840]: connection from XX.XX.it
Mar 20 16:31:48 6E:XX ftpd[43840]: RESTRICTED FTP LOGIN FROM XX.XX.it as XX
Mar 20 16:31:48 6D:XX ftpd[43840]: get /pub
Mar 20 16:31:53 6D:XX ftpd[43857]: connection from XX.XX.it
Mar 20 16:32:09 6D:XX ftpd[43840]: get /634504.pdf
Mar 20 16:32:13 6D:XX ftpd[43840]: get /pub

This log reveals TWO problems:
1. get instead of put
2. get /filename.ext instead of put /pub/filename.ext

I mean, not only SM DOES NOT UPLOAD but IT IS NOT AWARE OF CURRENT DIRECTORY /pub; if you "write" put instead of get in fron of fileXfer command, it is wrong, as the expected directory path (/pub) is missing.

I repeat, the initial url is:
ftp://myusername:mypassword@myhost.mydoma.in/mydir
After this command I see correctly the directory listing.
After this command I EXPECT (maybe wrong) to be able to use Upload command in order to put a file "there" (/mydir) not on /

Please ==> note that we are using a proxy <==, ftp proxy on port 8080, and this issue appears only using the proxy.
Proxy is (are, 2 different tested) SUN (Netscape) Proxy Server.

In a direct (local) environment SM works OK (maybe Phoenix was not behind a proxy but local to the server or exposed in internet?).

Snooping what ==> SM sends to proxy <== reveals that it issue a HTTP GET:

GET ftp://user:pass@host.domain.it/tmp/hdtv.txt HTTP/1.1
Host: host.domain.it
User-Agent: Mozilla/5.0 (Windows NT  5.1; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15 Lightning/2.0b1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Proxy-Authorization: Basic XXXXXXXX
Connection: keep-alive

The reply from proxy is (obviously) a "HTTP/1.0 500"

Any question like "how is configured the proxy" should be avoided: 
GET ftp://user:pass@host.domain.it/tmp/hdtv.txt HTTP/1.1
is NOT something to send to a (ftp or even http) proxy...

Both (autoconfiguration file, explicit proxy setting for all protocols) have been tested with same results.

I am willing to help, regards, Marco

Comment 7

5 years ago
(In reply to CADMO from comment #6)
> Any question like "how is configured the proxy" should be avoided
> I am willing to help, regards, Marco
This two sentences doesn't match ;)
Component: General → Networking: FTP
OS: Windows XP → All
Product: SeaMonkey → Core
Hardware: x86 → All
Whiteboard: closeme WFM 2013-04-01
Version: SeaMonkey 2.15 Branch → 18 Branch
(Reporter)

Comment 8

5 years ago
(In reply to Phoenix from comment #7)
> (In reply to CADMO from comment #6)
> > Any question like "how is configured the proxy" should be avoided
> > I am willing to help, regards, Marco
> This two sentences doesn't match ;)

If you believe so, the reason is that it is not so easy to correctly translate a concept from a foreign language into english.
So keep the second for true.
The first sentence was only related to the fact that:
"GET ftp://user:pass@host.domain.it/tmp/hdtv.txt HTTP/1.1"
seemed to me *** absolutely obvious *** that ftp server configuration questions would have been a waste of time.
Anyway, if you believe differently, please discard the first sentence.

Finally, due to the fact that from your (kind and correct) critic you seem disappointed, please EXCUSE ME.
Marco
(Reporter)

Comment 10

5 years ago
(In reply to Phoenix from comment #9)
> Check if problem exists in current nightly builds for both FF and SM
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-
> trunk/seamonkey-2.19a1.en-US.win32.zip
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-
> central/firefox-22.0a1.en-US.win32.zip
> Just unpack them to separate folders and run from there

1. checked SM as per instructions above.
2. problem EXISTS.
3. a window from SM shows up during the operation; title is [%xfer] of [filename] - [status]; content is From [filename] To [ftp://username:password@hostname.domai.in/destinationpathdir/ [transferedsize] of [totalsize] [elapsedtime] [status]; hope it is clear.
4. FF had NO ftp upload on my (old) desktop (7.x) version so I did what you requested about FF; no "upload ftp file" command found (same as my release) on latest FF release, maybe I am dumb...

To resume above: even with nightly build of SM (FF does not ftp upload) the problem is present; everything stated for SM used in this test is valid, and the same, with SM nightly build.

I am late but I had work to do, sorry for being late.

Comment 11

5 years ago
> FF does not ftp upload

That does appear to be the case, FF offers no way to upload to FTP, marked WONTFIX:
Bug 215673 - it is not possible to upload a file to an ftp server

Comment 12

5 years ago
Funny, I thought FF have support for uploading, but anyway.
CADMO, as nobody from developers doesn't step in, the fastest way to find, when this was broken, is to test previous release versions. Start from 2.1, if issue present there then test older versions, if not - that is good news, test newer versions.
Version: 18 Branch → Trunk
(Reporter)

Comment 13

5 years ago
Phoenix, that's quick and easy! 
SM 1.X all ok, SM 2.X none!
I had SM 1.x "till-the-end" (1.8.20090.40306 1.1.16 1.8.1.21:2009040306) as I found this bug in 2.0X. )should be 2.01, not sure)
I decided not to hasle as SM 2.X was a really hard matter to do, and I believed bug was known but in wait-list, but now, after so much time, I decided to report such a really important feature.

Unfortunately, afaik, from 1.x to 2.x the whole-world changed...

Comment 14

5 years ago
Ok, next step is longer and harder, you need to test 2.0 alpha and beta builds to determine, in which upload function became broken. Start from 2008 year builds - http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2008/, needed builds are in -trunk folders.
Also, if you have python installed, you can automate this process with mozregression tool from - https://wiki.mozilla.org/Auto-tools/Projects/RegressionHunter#mozregression
(Reporter)

Comment 15

5 years ago
OK Phoenix, but please be patient, I am NOT a... "mozill-oper"!
So, first, please check I understood.

Actions:
1. unneeded test of
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.14pre)
   Gecko/20080101 SeaMonkey/1.0.9
   RESULT: OK (seems to me obviously)
2. first directory with TRUNK subdir seen, first trunk subdir test. 
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) 
   Gecko/2008010102 SeaMonkey/2.0a1pre
   RESULT: OK (a thing todo well done, I hope!)
3. first directory with TRUNK subdir seen, last trunk subdir test. 
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre)
   Gecko/2008072102 SeaMonkey/2.0a1pre
   RESULT: OK (another thing todo well done, I hope!)
4. last directory with trunk subdir seen, last trunk subdir test
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre) 
   Gecko/2008072202 SeaMonkey/2.0a1pre
   RESULT: BAD1 (UploadFile, choose file, ok, NOTHING HAPPENS)
   Not the same problem, so unuseful experience
5. last directory with trunk subdir seen, previous trunk subdir test
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre) 
   Gecko/2008072102 SeaMonkey/2.0a1pre
   RESULT: BAD1 (UploadFile, choose file, ok, NOTHING HAPPENS)
   Not the same problem, so unuseful experience

So, I have to go on (later) respect trunk subdirs from step 3 and go down (previous) respect trunk subdirs from step 5 above till I found the last result ok going on and the first "same error I reported" going down, in a tipical search fashion, CORRECT??? Hope so!

No python, not to much time, I can go on checking (relaxed check), just - PLEASE - let me know if the way (I know it is not the best way) is CORRECT.

Cheers

Comment 16

5 years ago
Yeah, steps correct in general, but founding when "nothing happens" begins may be also useful because it may be source issue which later be fixed (for without proxy case), but not for your case.

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 17

5 years ago
OK Phoenix. A note on COMMENT#15
Test 2. and 3. (first directory with XXXX-trunk subdir seen) acted on 01
Test 4. and 5. (last  directory with XXXX-trunk subdir seen) acted on 07
No XXXX-trunk subdir seen on 08,09,10,11,12.

Actions:
1. 04 directory with TRUNK subdir seen, first trunk subdir test. 
   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) 
   Gecko/2008040101 SeaMonkey/2.0a1pre
   RESULT: BAD1 (UploadFile, choose file, ok, NOTHING HAPPENS)
   Not the same problem, see COMMENT#16 for usefulness of test

...going on...

Comment 18

5 years ago
(In reply to CADMO from comment #17)
> No XXXX-trunk subdir seen on 08,09,10,11,12.
For those dirs use comm-central subdir
(Reporter)

Comment 19

5 years ago
...going on...
1. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) 
   Gecko/2008020102 SeaMonkey/2.0a1pre
   RESULT: OK (uploaded as expected)
2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) 
   Gecko/2008033101 SeaMonkey/2.0a1pre
   RESULT: BAD1 (see COMMENT#17)
3. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
   Gecko/2008021501 SeaMonkey/2.0a1pre
   RESULT: OK
4. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
   Gecko/2008022901 SeaMonkey/2.0a1pre
   RESULT: BAD1
5. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
   Gecko/2008022202 SeaMonkey/2.0a1pre
   RESULT: OK
6. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
   Gecko/2008022702 SeaMonkey/2.0a1pre
   RESULT: BAD1
7. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
   Gecko/2008022502 SeaMonkey/2.0a1pre
   RESULT: OK
8. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
   Gecko/2008022601 SeaMonkey/2.0a1pre
   RESULT: OK

> in which upload function became broken

Gecko/2008022601 is OK
Gecko/2008022702 is BAD

As per test above, using Gecko/2008022601 this bug does not show up and FTP (via proxy) UPLOAD IS 100% OK; starting with Gecko/2008022702 it is no more possible to do "upload the same way" you can do with Gecko/2008022601.

==> So something seems to broke after Gecko/2008022601 <==

I think that to check "in which build the bug becomes the same" it is of no use: if brakes are broken in a car, you do not mind if you crash right side or left side... but I am not enough skilled as a "Mozill-Over" (Developer of Mozilla) to say more than "I thing".

Step requested as per COMMENT#12 and COMMENT#14 are DONE.
Hope it could help. Let me know.
Cheers, Marco
(Reporter)

Comment 20

5 years ago
Please note the following (IMPORTANT).
There is a change in history, made by pppx@i.com.ua on 2013-03-20 11:43:11 PDT.
OS 	Windows XP 	All 
Hardware 	x86 	All 
No matter for Hardware, but OS ==> may <== have been changed wrong.
I made the same test (FTP UPLOAD via PASSWORD PROTECTED PROXY to a PASSWORD PROTECTED FTP SITE) using SeaMonkey on a SGI Origin IRIX server:
Mozilla/5.0 (X11; U; IRIX64 IP27; en-US; rv:1.8.1.13) 
Gecko/20080326 SeaMonkey/1.1.9
and IT WORKS OK.

Gecko/20080326 on it seems a later release respect the buggy Gecko/2008022702

As I wrote above, I have not enough skill to say if Gecko/20080326 and Gecko/2008022601 are the elements to be checked, or SeaMonkey/1.1.9 and SeaMonkey/2.0a1pre are, or rv:1.8.1.13 and rv:1.9b4pre are, so please just keep this as an additional investigation.

Comment 22

5 years ago
(In reply to CADMO from comment #19)

Get temporary access to system with proxy and made tests on those build, results are funny: uploading works if I start from root ftp folder, but failing if I go directly to subfolder. Current builds, on other hand, fail in any case. I've made another quick test to determine, when uploading was broken again and it was SeaMonkey 2.15 release. So, now you need to determine new regression range, start folder is
ftp://ftp.mozilla.org/pub/seamonkey/nightly/2012/08/2012-08-28-00-30-36-comm-central-trunk/ - Working
End folder
ftp://ftp.mozilla.org/pub/seamonkey/nightly/2012/10/2012-10-08-00-30-26-comm-central-trunk/ - Broken, upload window doesn't close
But in 2.15 release it closes, so it may be worth checking 2.15a2 comm-aurora builds starting from
ftp://ftp.mozilla.org/pub/seamonkey/nightly/2012/10/2012-10-09-01-30-07-comm-aurora/
to find where upload dialog became working again
Don't forget to upload to root ftp folder now :)
(Reporter)

Comment 23

5 years ago
(In reply to Phoenix from comment #21)
> (In reply to CADMO from comment #19)
> > Gecko/2008022601 is OK
> > Gecko/2008022702 is BAD
> 
> > Hope it could help. Let me know.
> > Cheers, Marco
> 
> Okay, we find first root (not what we needed, but...), on that build
> uploading was broken by Bug 412822 and first part was fixed in Bug 495291
> (almost a year after), second in Bug 467524 (another year after).
> Builds, which need to test now, are
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2010/02/2010-02-28-
> 01-comm-1.9.1/seamonkey-2.0.4pre.en-US.win32.zip
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2010/03/2010-03-01-
> 08-comm-1.9.1/seamonkey-2.0.4pre.en-US.win32.zip
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2010/03/2010-03-02-
> 00-comm-1.9.1/seamonkey-2.0.4pre.en-US.win32.zip
> And separate
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2010/04/2010-04-05-
> 01-comm-central-trunk/seamonkey-2.1a1pre.en-US.win32.zip
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2010/04/2010-04-06-
> 03-comm-central-trunk/seamonkey-2.1a1pre.en-US.win32.zip
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2010/04/2010-04-07-
> 03-comm-central-trunk/seamonkey-2.1a1pre.en-US.win32.zip

RESULTS:

1 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100228 SeaMonkey/2.0.4pre
DOES NOTHING

2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100301 SeaMonkey/2.0.4pre
OK OK OK

3 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100302 SeaMonkey/2.0.4pre
OK OK OK

4 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100405 SeaMonkey/2.1a1pre
DOES NOTHING

5 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100406 SeaMonkey/2.1a1pre
OK OK OK

6 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100407 SeaMonkey/2.1a1pre
OK OK OK

DOES NOTHING: after selecting file to upload, click ok and... nothing happens
OK OK OK: works as expected (PUT the file on FTP server subdirectory)
(Reporter)

Comment 24

5 years ago
(In reply to Phoenix from comment #22)
> (In reply to CADMO from comment #19)
> ...
> (A) results are funny: uploading works if ...
> (B) ... now you need to determine new regression range, 
> start folder is 2012/08/2012-08-28-00-30-36-comm-central-trunk/ - Working
> End folder      2012/10/2012-10-08-00-30-26-comm-central-trunk/ - Broken
> (C) ... it may be worth checking 2.15a2 comm-aurora builds starting from
> 2012/10/2012-10-09-01-30-07-comm-aurora/
> ...
> (D) Don't forget to upload to root ftp folder now :)

(A) You should "snoop" your accesses, as I "feel" password is sent only 1. if requested or 2. if on commandLine (URL). If you use commandLine (URL) to access to root and send therefore password, then PUT ok it "could be" ftp server (or proxy?) understanding correctly the access; If you use commandLine (URL) to access to root and issue a get to access subdirectory and issue a PUT it "could be" ftp server (or proxy?) understanding your action as a "different" session without password; this is true if you consider the fact that "ftp sessions" are auth (otherwise if you connect via proxy to ftp.x.y and me - using same proxy - too, I'd have access to a protected area). Hope this is clear... anyway, the point is "snoop what happens if something goes strange".

(B) Dou you mean that after:

Gecko/2008022601 is OK
Gecko/2008022702 is BAD
==> So something seems to broke after Gecko/2008022601 <==

some more actions are needed?

If so, please explain again (I understand: download all "...comm-central-trunk/" in sep, part of oct and nov, and repeat test) as I am not sure I understood correctly.

(C) same as (B) above

(D) I had a couple of week hard here, next weeks will be worst, hope to have spare time, no promise (if you can hire me, it will be different!!!), but most important is: "sorry, cannot get the :) part of that, my fault!!!". Due to (A) explanation is needed, as I agree with :) if it means "a quick way to have all ok is to upload on root folder" but as per my (A) above my opinion is that protocols (ftp, proxy) and software (Mozilla included, sorry!) are... @!#!#@!@@#! (word censured) so that sometimes a :) easily becomes a :( OR MAYBE I AM JUST TIRED, that's the reason for I wrote "sorry" a few lines above!

Pls reply to (B) as well as to #20 (a 1. OK and 2. NA are fine).

Comment 25

5 years ago
(In reply to CADMO from comment #24)
> (B) Dou you mean that after:
> 
> Gecko/2008022601 is OK
> Gecko/2008022702 is BAD
> ==> So something seems to broke after Gecko/2008022601 <==
> 
> some more actions are needed?
> 
> If so, please explain again (I understand: download all
> "...comm-central-trunk/" in sep, part of oct and nov, and repeat test) as I
> am not sure I understood correctly.
Yes, you understand right, also it may be worth checking builds from november and later from comm-aurora/ folders
We are in a period where ftp is clearly deprecated and in general, making changes to the code is riskier than letting it ride unless there is a patch and reviewer available to make a good judgment about it. So I'm going to wontfix ftp bugs related to enhancements, interop errors, etc.. We will be better off putting our energy into including a different js based ftp stack.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.