[PEP 243] upload status is bogus
I just read thru PEP 243 and got to the section "Return Data". That information is bogus. HTTP already provides the upload client with various status codes. Specifically, let's look at the list in the PEP: PEP value HTTP Status SUCCESS 200 (Ok) FAILURE 4xx or 5xx TRYAGAIN 4xx or 5xx The PEP lists "resource shortage" as a possible TRYAGAIN error. That would map to 507 (Insufficent Storage). I'm sure there are other values that would make sense within this area. The PEP goes on to say that a human-readable string should provide further information. That is exactly what the body of the HTTP response is for. So... the answer here is to use the HTTP status codes like they're intended, and to use the HTTP response body as they're intended. This beats added another protocol layer on top of the response. Cheers, -g p.s. I'm not on the Distutils-SIG; I'd appreciate a CC for replies. -- Greg Stein, http://www.lyra.org/
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? As soon as you get the search.python.org web page to return "404" (not found) when it doesn't locate any matches, I'll look at changing it. Sean -- "Self-taught just means that you don't have to get rid of other people's prejudices as well as your own." -- Sean Reifschneider, 1997 Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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/
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".
[ 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". The repository system has repeatedly suffered because of trying to make it perfect. 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. As far as I know, I'm following the standards. 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... 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...
At a minimum, the PEP should incorporate this alternate suggestion for reporting status.
Meaning that all clients *HAVE* to support both methods? That's what the "protocol_version" field is for -- if I'm convinced it's the right way to go, I'll set up the server so it can handle both methods, change the PEP to use the HTTP codes *ONLY*. Sean -- Brooks's Law of Prototypes: Plan to throw one away, you will anyhow. Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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/
Greg Stein <gstein@lyra.org> writes: [...]
So... the answer here is to use the HTTP status codes like they're intended, and to use the HTTP response body as they're intended. This beats added another protocol layer on top of the response.
I'm not sure if I really agree with this. It looks like other protocols on top of HTTP, such as xmlrpc, always return an HTTP status of 200 whatever he result. Relying on a mapping between HTTP statuses and swalow return values seems a bit fragile to me. I would actually prefer the response to be completely in the HTTP body, probably as another set of RFC 822 headers. This properly separates the transport from the swalow protocol. This would make the complete response from the server something like: """\ HTTP/1.0 200 OK Date: Tue, 27 Mar 2001 12:27:10 GMT Server: SomeWebServer Connection: close Content-Length: 84 Content-Type: application/x-swalow-response Swalow-Status: TRYAGAIN This body text is what was described for X-Swalow-Reason. """ Of course, it *is* late at night and I may not know what I'm talking about... -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion."
participants (3)
-
Carey Evans -
Greg Stein -
Sean Reifschneider