Issue 5399053: Use Accept header in upload.py to print out plain text error messages. (Closed)
DescriptionOlder versions of upload.py (and other wrapper scripts) will still see the ugly traceback. My instance on http://rvtests.appspot.com understands the Accept header and has writes disabled for testing.
Patch Set 1 #
Total comments: 1
MessagesTotal messages: 9
LGTM I understand your desire to distinguish between upload.py and web browsers, but we already have a mechanism: the @upload_required decorator (which unfortunately is a no-op). Alas, it seems no matter what we do, a modified version of upload.py is needed, so it doesn't really matter for the currently planned outage (in less than 2 hours), hence the LG. http://codereview.appspot.com/5399053/diff/1/upload.py File upload.py (right): http://codereview.appspot.com/5399053/diff/1/upload.py#newcode402 upload.py:402: ## elif e.code >= 500 and e.code < 600: Better delete this block.
Sign in to reply to this message.
On Thu, Nov 17, 2011 at 11:03 AM, Andi Albrecht <albrecht.andi@googlemail.com> wrote: > On Thu, Nov 17, 2011 at 7:59 PM, Guido van Rossum <guido@python.org> wrote: >> Thanks, I'll deploy this now. But if I don't get a hold of one of our >> super sysadmins soon the migration will be a dud -- it got stuck and >> getting it unwedged exceeds my skills... > > hm, I'm sorry to hear that. Crossing my fingers that you get it > running again! Let us know :) Apparently it's running, just very slow. We may have to extend the downtime. There's no way back. :-( -- --Guido van Rossum (python.org/~guido)
Sign in to reply to this message.
On Thu, Nov 17, 2011 at 8:13 PM, Guido van Rossum <guido@python.org> wrote: > On Thu, Nov 17, 2011 at 11:03 AM, Andi Albrecht > <albrecht.andi@googlemail.com> wrote: >> On Thu, Nov 17, 2011 at 7:59 PM, Guido van Rossum <guido@python.org> wrote: >>> Thanks, I'll deploy this now. But if I don't get a hold of one of our >>> super sysadmins soon the migration will be a dud -- it got stuck and >>> getting it unwedged exceeds my skills... >> >> hm, I'm sorry to hear that. Crossing my fingers that you get it >> running again! Let us know :) > > Apparently it's running, just very slow. We may have to extend the > downtime. There's no way back. :-( At least it's running! Can you already make a rough guess on how long it will take? > > -- > --Guido van Rossum (python.org/~guido) >
Sign in to reply to this message.
On Thu, Nov 17, 2011 at 4:13 PM, <gvanrossum@gmail.com> wrote: > LGTM > > I understand your desire to distinguish between upload.py and web > browsers, but we already have a mechanism: the @upload_required > decorator (which unfortunately is a no-op). Yes, I was hesitating a bit in choosing this direction. But returning a plain text response should satisfy upload.py and possible some wrapper scripts too. IMO sending "Accept: text/plain" should be good as an identifier for any script talking to our server. But as said before, I'm not 100% sure about this. @upload_required should then use the same mechanism of course. > > Alas, it seems no matter what we do, a modified version of upload.py is > needed, so it doesn't really matter for the currently planned outage (in > less than 2 hours), hence the LG. > > > http://codereview.appspot.com/5399053/diff/1/upload.py > File upload.py (right): > > http://codereview.appspot.com/5399053/diff/1/upload.py#newcode402 > upload.py:402: ## elif e.code >= 500 and e.code < 600: > Better delete this block. Done - writing it here in this mail, since codereview.appspot.com is returning CapabilityDisabled ATM :) --Andi > > http://codereview.appspot.com/5399053/ >
Sign in to reply to this message.
Thanks, I'll deploy this now. But if I don't get a hold of one of our super sysadmins soon the migration will be a dud -- it got stuck and getting it unwedged exceeds my skills... On Thu, Nov 17, 2011 at 10:40 AM, Andi Albrecht <albrecht.andi@googlemail.com> wrote: > On Thu, Nov 17, 2011 at 4:13 PM, <gvanrossum@gmail.com> wrote: >> LGTM >> >> I understand your desire to distinguish between upload.py and web >> browsers, but we already have a mechanism: the @upload_required >> decorator (which unfortunately is a no-op). > > Yes, I was hesitating a bit in choosing this direction. But returning > a plain text response should satisfy upload.py and possible some > wrapper scripts too. IMO sending "Accept: text/plain" should be good > as an identifier for any script talking to our server. But as said > before, I'm not 100% sure about this. @upload_required should then use > the same mechanism of course. > >> >> Alas, it seems no matter what we do, a modified version of upload.py is >> needed, so it doesn't really matter for the currently planned outage (in >> less than 2 hours), hence the LG. >> >> >> http://codereview.appspot.com/5399053/diff/1/upload.py >> File upload.py (right): >> >> http://codereview.appspot.com/5399053/diff/1/upload.py#newcode402 >> upload.py:402: ## elif e.code >= 500 and e.code < 600: >> Better delete this block. > > Done - writing it here in this mail, since codereview.appspot.com is > returning CapabilityDisabled ATM :) > > --Andi > >> >> http://codereview.appspot.com/5399053/ >> > -- --Guido van Rossum (python.org/~guido)
Sign in to reply to this message.
Couple more hours. I'll update the message on the site and send out another email. On Thu, Nov 17, 2011 at 11:17 AM, Andi Albrecht <albrecht.andi@googlemail.com> wrote: > On Thu, Nov 17, 2011 at 8:13 PM, Guido van Rossum <guido@python.org> wrote: >> On Thu, Nov 17, 2011 at 11:03 AM, Andi Albrecht >> <albrecht.andi@googlemail.com> wrote: >>> On Thu, Nov 17, 2011 at 7:59 PM, Guido van Rossum <guido@python.org> wrote: >>>> Thanks, I'll deploy this now. But if I don't get a hold of one of our >>>> super sysadmins soon the migration will be a dud -- it got stuck and >>>> getting it unwedged exceeds my skills... >>> >>> hm, I'm sorry to hear that. Crossing my fingers that you get it >>> running again! Let us know :) >> >> Apparently it's running, just very slow. We may have to extend the >> downtime. There's no way back. :-( > > At least it's running! Can you already make a rough guess on how long > it will take? > >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (python.org/~guido)
Sign in to reply to this message.
On Thu, Nov 17, 2011 at 7:59 PM, Guido van Rossum <guido@python.org> wrote: > Thanks, I'll deploy this now. But if I don't get a hold of one of our > super sysadmins soon the migration will be a dud -- it got stuck and > getting it unwedged exceeds my skills... hm, I'm sorry to hear that. Crossing my fingers that you get it running again! Let us know :) > > On Thu, Nov 17, 2011 at 10:40 AM, Andi Albrecht > <albrecht.andi@googlemail.com> wrote: >> On Thu, Nov 17, 2011 at 4:13 PM, <gvanrossum@gmail.com> wrote: >>> LGTM >>> >>> I understand your desire to distinguish between upload.py and web >>> browsers, but we already have a mechanism: the @upload_required >>> decorator (which unfortunately is a no-op). >> >> Yes, I was hesitating a bit in choosing this direction. But returning >> a plain text response should satisfy upload.py and possible some >> wrapper scripts too. IMO sending "Accept: text/plain" should be good >> as an identifier for any script talking to our server. But as said >> before, I'm not 100% sure about this. @upload_required should then use >> the same mechanism of course. >> >>> >>> Alas, it seems no matter what we do, a modified version of upload.py is >>> needed, so it doesn't really matter for the currently planned outage (in >>> less than 2 hours), hence the LG. >>> >>> >>> http://codereview.appspot.com/5399053/diff/1/upload.py >>> File upload.py (right): >>> >>> http://codereview.appspot.com/5399053/diff/1/upload.py#newcode402 >>> upload.py:402: ## elif e.code >= 500 and e.code < 600: >>> Better delete this block. >> >> Done - writing it here in this mail, since codereview.appspot.com is >> returning CapabilityDisabled ATM :) >> >> --Andi >> >>> >>> http://codereview.appspot.com/5399053/ >>> >> > > > > -- > --Guido van Rossum (python.org/~guido) >
Sign in to reply to this message.
|
