[Distutils] [PEP 243] upload status is bogus

[Greg Stein]

On Tue, Mar 27, 2001 at 04:50:43AM -0700, Sean Reifschneider wrote:
> On Mon, Mar 26, 2001 at 02:59:14PM -0800, Greg Stein wrote:
> >information is bogus. HTTP already provides the upload client with various
> >status codes. Specifically, let's look at the list in the PEP:
> 
> It's bogus to use the transport status to signal an application return
> status.  Any non-200 transport status should (and is, according to my
> PEP) interpreted as a temporary failure.  How would you differentiate
> between a "400" (bad request) which is the application signaling that the
> request was invalid and the web server reporting it because of a
> configuration error or the like?  The former being a permanent application
> failure, and the latter being temporary?

4xx failures mean "you can probably fix it and resubmit."  5xx failures are
"just give up, buddy." If a web server reports 4xx because of a config
error, then the web server is busted.
[ and yes, I'm sure you can find a situation where the config is "fine" and
  a 4xx is reported, yet the client can do nothing; that is beside the point
  I'm making here. ]

The application in question is shoving data at an HTTP server. The HTTP
status code is the appropriate way to report status in this situation. You
don't have an "application (-level) return status". The server accepts it,
it doesn't, or it suggests that you try again. That maps directly to the
HTTP status codes.

HTTP is for moving content about. Those status codes are how the web server
reports what is done with the content, and what the client can/should do
about it.

The current description in the PEP is effectively defining another layer of
protocol on top of HTTP, when HTTP already incorporates everything needed.
We don't need Yet Another Protocol.

[ and don't even get me started on how the package is uploaded; I'm playing
  soft here; those MD5 checksums and the multipart stuff have alternatives
  that are more in line with HTTP (see the Content-MD5 header); heck, the
  PUT method may be more appropriate; I'm just not touching those issues
  because they are small potatoes relative to introducing new error
  reporting systems. ]

At a minimum, the PEP should incorporate this alternate suggestion for
reporting status.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/