Could you please update to a more recent rekonq version? (e.g. 0.4.95 or compile it directly from the git repository) There were tons of bugfixes, and your bug might be fixed too.

It doesn't work for me too.

rekonq 0.5.81

+1

I'm not 100% sure about this, but I think this should be impossible (or very tricky) without using kparts.
And in general, our main design is being just a "browser", not a "file manager". That's our main difference with konqueror and I expext you cannot do this also with Firefox, Opera, Chrome, etc...

Caveat: This is based on my limited understanding of the foundational KDE components. But I would think this is possible using just KIO. Does KIO require KParts? Does rekonq not use KIO for accessing the http protocol?

That has absolutely nothing to do with KParts?!

Also there is nothing tricky about using a function that supports non-local files...

const QString destUrl = KFileDialog::getSaveUrl(name, QString(), this, QString(), KFileDialog::ConfirmOverwrite).url();

(In reply to comment #6)
> That has absolutely nothing to do with KParts?!
> 
> Also there is nothing tricky about using a function that supports non-local
> files...
> 
> const QString destUrl = KFileDialog::getSaveUrl(name, QString(), this,
> QString(), KFileDialog::ConfirmOverwrite).url();

Uhm.. I probably explained myself badly. 
Let's say you are browsing a local path, copy a file and you wanna save (paste) it in a remote dir. This operation (tipical in file managers) is not implemented in rekonq and the easiest way I'm aware to implement it is using a kpart.
Now, let's say you are browsing a local file (eg: $HOME/foo.pdf) and you wanna save it in a remote dir (sftp://bar/code/etc..). You select the "save as" action in the tools menu, browse to the remote dir with the save dialog and then press save. This operation has nothing to do with kparts and can be implemented with the code you pointed out. Quite the same of the saveas rekonq function.
So, what's the requested use case? The first one is a WONTFIX, while the second one should work out of the box. 
Waiting your reply, I'm going to try a save in my web space :)

Even for the first presented use case you supposedly just need to get a KIO job started that copies the URL gathered from a local browsing location to a remote one (well, plus drag tracking and/or context menu foo). IMHO that is how ever simple it might be to do, indeed outside the scope of Rekonq.

But from the original steps for reproducing the issue I gather saving a random object of a website (or the website itself for that matter) onto a remote location is the desired functionality here.

>Steps to Reproduce:
> Find an image, right click to save it. Navigate to a remote folder e.g. over
> sftp. Click okay. Rekonq refuses to accept the path, does not save.

Which makes sense when you for example have a sophisticated Samba setup (think company) and one person wants to quickly share something she found on the web with another person -> this might very well happen via smb://foo/all.

This is a pretty annoying bug that didn't exist in Konqueror. Here's one example: I have a home theater PC in my living room and a KDE desktop computer in my office. From my office, I'd like to right-click -> "Save link..." on a .torrent or video file that's linked from someone's web page and save it straight to my HTPC in one step.

I can easily set up an entry in the "Places" menu on the left side of the Rekonq Save As dialog for my HTPC (using sftp), and I can click on that entry to browse through its folders... but when I click save, it gives me an error. Why even let me browse there then?

Thi has nothing to do with being a file manager... most other KDE applications can "save as" to remote locations just fine. Examples include Kate, KolourPaint, Krita, K3b, and of course Konqueror. The programs that do share this error are generally non-KDE such as Firefox and LibreOffice so I'm more forgiving of those ones when they don't play nice with the KDE dialogs... but if Rekonq is supposed to be "the KDE browser" this should be fixed.

Oh my God, I'm really sorry to say I completely misunderstood the problem until... now! I tried a similar case and I can fully confirm the bug. Also if the problem seems a bit mysterious: IMHO this should work out of the box.
Targetting this for... the evening!

Still not working, in Kubuntu 11.10; Rekonq 0.8.

Has there been any developer activity on this bug?

Yes. I checked konqueror code and compared with rekonq one about this. They look pretty similar...

Pretty similar, yet not the same; Rekonq still won't save a file over a remote directory.

I'm not sure what's going on here; surely Rekonq uses the file:// kioslave to save locally, what's stopping it using, say, the smb:// or ftp:// or webdav:// kioslaves?

Git commit bec0deb0925091d2b26038deed730c72af9c0a37 by Andrea Diamantini.
Committed on 03/11/2011 at 16:25.
Pushed by adjam into branch 'master'.

Let rekonq save file remotely

Andreas's comment was helpful: rekonq COULD save file remotely, but
for same strange reason, KFileDialog::getSaveFileName() could not
select remote files. Switching to getSaveUrl seems fixing the problem

Ah... also a style clean up here. Sorry for the merged commit...

BUG: 242675

M  +3    -3    src/mainwindow.cpp
M  +1    -1    src/settings/webkitwidget.h
M  +3    -3    src/tabbar.cpp
M  +6    -6    src/urlbar/urlbar.cpp
M  +1    -1    src/urlbar/urlresolver.cpp
M  +1    -1    src/webpluginfactory.cpp

http://commits.kde.org/rekonq/bec0deb0925091d2b26038deed730c72af9c0a37