从用户那里收集文件

发布于 2024-08-08 22:57:07 字数 548 浏览 5 评论 0原文

我正在寻找从客户那里收集文件的方法。这些客户拥有我们的软件,我们目前正在使用 FTP 从他们那里收集文件。文件从客户的数据库中收集、加密并通过 FTP 上传到我们的 FTP 服务器。这个过程充满了挫折和障碍。该软件经常被常见防火墙阻止,并且经常遇到 VPN 和 NAT 困难(切换到被动而不是主动通常会有所帮助)。

我的问题是,人们对于以可靠的方式以编程方式从客户端获取文件还有什么其他想法。他们提交的大多数文件都<大小为 1 MB。然而,其中之一的大小高达 25 MB。

我考虑过 HTTP POST,但是,我担心 25 mb 的文件经常会在帖子上发生故障(Web 服务器在文件完全上传之前超时)。

想法?

AndrewG

编辑:我们可以使用任何常见的网络技术。我们使用共享主机,这可能会使中央配置更改变得困难。我从常见使用的角度熟悉 PHP...但从设置的角度不熟悉(编写了大量代码,但没有陷入任何过于繁重的任务)。 Ruby on Rails 也是可能的......但我会从头开始。理想情况下......我正在寻找一种“网络”方式来执行此操作,因为我希望最终准备好从已安装的代码进行转换。

I'm looking for ways to gather files from clients. These clients have our software and we are currently using FTP for gathering files from them. The files are collected from the client's database, encrypted and uploaded via FTP to our FTP server. The process is fraught with frustration and obstacles. The software is frequently blocked by common firewalls and often runs into difficulties with VPNs and NAT (switching to Passive instead of Active helps usually).

My question is, what other ideas do people have for getting files programmatically from clients in a reliable manner. Most of the files they are submitting are < 1 MB in size. However, one of them ranges up to 25 MB in size.

I'd considered HTTP POST, however, I'm concerned that a 25 mb file would often fail over a post (the web server timing out before the file could completely be uploaded).

Thoughts?

AndrewG

EDIT: We can use any common web technology. We're using a shared host, which may make central configuration changes difficult to make. I'm familiar with PHP from a common usage perspective... but not from a setup perspective (written lots of code, but not gotten into anything too heavy duty). Ruby on Rails is also possible... but I would be starting from scratch. Ideally... I'm looking for a "web" way of doing it as I'd like to eventually be ready to transition from installed code.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

过期以后 2024-08-15 22:57:07

研究 scp 和 rsync。

Research scp and rsync.

孤寂小茶 2024-08-15 22:57:07

一种选择是在浏览器中运行一些东西,将上传分成块,这有望使其更加可靠。执行此操作的控件还会在上传过程中向用户提供一些反馈,这是通过简单的 HTTP POST 无法获得的。

Google 很快就发现了这个免费 Java Applet,它就可以做到这一点。将会有很多其他免费和付费的选项可以做同样的事情

One option is to have something running in the browser which will break the upload into chunks which would hopefully make it more reliable. A control which does this would also give some feedback to the user as the upload progressed which you wouldn't get with a simple HTTP POST.

A quick Google found this free Java Applet which does just that. There will be lots of other free and pay for options that do the same thing

菊凝晚露 2024-08-15 22:57:07

您可能指的是 HTTP PUT。这应该像魅力一样发挥作用。如果你有一个像样的网络服务器。但据我所知,它无法重新启动。

FTP是正确的选择(通过防火墙的被动模式)。如果您经常遇到 VPN 连接故障(酒店网络太糟糕了:-))麻烦,请使用支持可重新启动传输的 FTP 服务器。

必须支持的 FTP 命令是REST

来自 http://www.nsftools.com/tips/RawFTP.htm

Syntax: REST position

集文件传输应该开始的点;对于恢复中断的传输很有用。对于非结构化文件,这只是一个十进制数。该命令必须紧接在数据传输命令之前(仅限 RETRSTOR);即它必须位于任何 PORTPASV 命令之后。

You probably mean a HTTP PUT. That should work like a charm. If you have a decent web server. But as far as I know it is not restartable.

FTP is the right choice (passive mode to get through the firewalls). Use an FTP server that supports Restartable transfers if you often face VPN connection breakdowns (Hotel networks are soooo crappy :-) ) trouble.

The FTP command that must be supported is REST.

From http://www.nsftools.com/tips/RawFTP.htm:

Syntax: REST position

Sets the point at which a file transfer should start; useful for resuming interrupted transfers. For nonstructured files, this is simply a decimal number. This command must immediately precede a data transfer command (RETR or STOR only); i.e. it must come after any PORT or PASV command.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文