[Distutils] [PEP 243] upload status is bogus

[Greg Stein]

On Tue, Mar 27, 2001 at 06:12:59AM -0700, Sean Reifschneider wrote:
> On Tue, Mar 27, 2001 at 04:20:55AM -0800, Greg Stein wrote:
> >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
> 
> For this application, a 500 error should be considered a temporary failure.
> I believe that HTTP should report 200 if it successfully ran the CGI,
> anything else if it did not.  I would hardly call making use of the X-
> headers "Yet Another Protocol".

But 200 implies everything was OK with the transaction, when it really
wasn't. Those status codes aren't simply "did you run the script for me" but
a response about what the server *did*.

> >[ 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
> 
> "playing soft here"?  Geeze, this isn't some competition...  This whole
> section in the brackets makes it sound like you were just holding those
> comments back so you could make me look like an idiot if I didn't respond
> favorably to your initial message proclaiming my work "bogus".

Not my intent to be a competition or to hold back or even think of calling
you or anyone else and idiot(!). Simply that I saw a number of changes that
could be done, but I just don't care to push on. How the data is marshalled
over the wire (multipart or some other mechanism) is mostly noise. Many
options work, and I think there are other choices, but they simply don't bug
me enough to speak up :-). The point is that I think you've selected a fine
way to marshal the package. The bracket-comment was saying that I'm not
trying to be annoying... if I was, then I could dredge up all kinds of muck
to throw about :-)

Please excuse the word "bogus" in the initial subject line. I'm not saying
your *work* is bogus. That was simply a word choice for how the errors are
reported. Maybe it sounds harsh, but that's not the intent. Ask anybody...
I'm not the kind the guy to harsh on a person.

And the brackets are just my way of marking a side-comment. i.e. not part of
the discussion and safely ignored.

> The repository system has repeatedly suffered because of trying to make it
> perfect.

Not suggesting perfection. Just a simple change to error reporting. As
above, I'm explicitly avoiding numerous tweaks because in the larger scheme
of things, they just don't fuggin matter :-)

> I'm not going to commit the HTTP RFCs to memory just to track
> down some vague mentions you make about my not conforming to spec.

No need for you to memorize them. I've been living and breathing them for
several years now. Only one person needs the brain pollution :-)

> As far as I know, I'm following the standards.

You are; I just think that you can "lower the impedance" with HTTP in this
one case.

> The "multipart stuff" is RFC1867,
> and I'd submit that they defined X- application-specific headers for a
> reason.  Is there an RFC which says that applications running on top of
> HTTP *MUST* use HTTP response codes in preference to X- headers,
> Content-MD5, etc?  I honestly don't know...

There aren't any RFCs that say that. It is essentially more a design gestalt
than anything. Long hours, days, weeks, ... hell, the past two years :-)
dealing with WebDAV, and its design philosophy for leveraging HTTP plus a
lot of queries to Roy Fielding plus implementation... just kinda makes me a
bit knee-jerk about how to build apps/systems on top of HTTP.

> If you want to describe more fully your other suggestions, I'd be
> interested in hearing them.  I've already taken note of the Content-MD5
> header, that one could be nice...

[ woah. looks like the PEP was updated in the past 12 hours ]

Well, it mostly depends on whether the submission will always be done with
client software, or whether you want to allow a browser to do it.

One point: if a browser will be uploading (via the example <FORM> in the
PEP), then the X- headers won't help out the browser user (the 200 OK will
make everything appear hunky dory to the user). If we assume that is
changed, per my suggestion, then you'd be browser-compatible with an upload.

However... if you wanted to only use software-driven uploads, then your MD5s
would go into the Content-MD5 header in each part. The platform and the new
protocol-version would become X-Headers. At this point, if the client
doesn't submit a pkginfo (deferring to the contained PKG-INFO file), then
you wouldn't even need a multipart file. The distribution itself could be
the body of the POST message. Finally, there is a possible consideration to
use Content-Encoding for noting a compression for the transfer; this implies
the server will decompress the file, but that is actually a potential plus
-- the server could then create a .Z, .gz, and .bz2 for the distro. Dunno on
the Content-Encoding, but there is a possibility here.

There is no signature mechanism in pure HTTP; it is only SSL, and that is a
hairball to completely avoid. Using a PGP signature as an attachment is an
excellent thought.

> >At a minimum, the PEP should incorporate this alternate suggestion for
> >reporting status.
> 
> Meaning that all clients *HAVE* to support both methods?

Oh, geez no!

The PEP is supposed to capture discussion and alternatives for historical
record. Thus, two years from now, when somebody goes, "why didn't they use
HTTP status codes?", they can see the PEP and the rationale for not using
them. Or vice-versa.

IOW, the PEP isn't only "this is how it will be done", but also "here are
the alternatives that were discussed, and accepted/rejected." It keeps the
same arguments from arising all the time :-) With the info in the PEP, you
can say, "been there, done that. read the PEP and go away" :-)

Cheers,
-g

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