You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Wed, Jan 10 2018, Thomas Güttler wrote:
But maybe we could agree on the basic usage of http.
I consider an upload successful if the http server replies with "201".
This number was chosen because some web servers reply with 200 in case
of on error and display a "user friendly" page.
I currently return 200, since I never return a valid 2xx code for
errors. After the upload, the resource location is given in the JSON
response, not in the Location header.
Although 201 sounds nice in theory, at least for the REST backend.
The only issue is that after upload, a client attempting to follow to
the location might already trigger a download (which in "dl" case means
triggering premature expiration).
I was looking for a simple way to upload several files via http.
For ftp there are several hundred clients, but not for http :-(
I wrote one myself some weeks ago: https://github.com/guettli/tbzuploader
My tool is much simpler than yours.
But maybe we could agree on the basic usage of http.
I consider an upload successful if the http server replies with "201".
This number was chosen because some web servers reply with 200 in case of on error and display a "user friendly" page.
Several files can get uploaded at once and be default the key name "files" get used.
With which http status code does your server part respond if the upload was successful?
The text was updated successfully, but these errors were encountered: