From owner-freebsd-bugbusters@FreeBSD.ORG Fri Apr 8 20:34:09 2005 Return-Path: Delivered-To: freebsd-bugbusters@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9099516A4CE for ; Fri, 8 Apr 2005 20:34:09 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82E3543D1F for ; Fri, 8 Apr 2005 20:34:07 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a156.otenet.gr [212.205.215.156]) j38KX8vB018558; Fri, 8 Apr 2005 23:33:09 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j38KY2hA044561; Fri, 8 Apr 2005 23:34:03 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j38KY2h0044551; Fri, 8 Apr 2005 23:34:02 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 8 Apr 2005 23:34:02 +0300 From: Giorgos Keramidas To: Alan Larson Message-ID: <20050408203401.GA42151@gothmog.gr> References: <20050408083517.GF19136@submonkey.net> <200504082027.j38KRbY1097490@w6yx.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504082027.j38KRbY1097490@w6yx.stanford.edu> cc: bugbusters@freebsd.org Subject: Re: random text in bug submission. X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Coordination of the Problem Report handling effort. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2005 20:34:09 -0000 On 2005-04-08 13:27, Alan Larson wrote: >>On Thu, Apr 07, 2005 at 04:56:11PM -0700, Alan Larson wrote: >>> I entered the correct code, and it said it didn't match and >>> refused to take my bug submission. >>> >>> What an annoyance. >>> >>> It showed the same code as a previous report, but did not accept >>> the entry. >> >> I really don't understand this behaviour. The image is called as a >> volatile script (/cgi/sendpr-code.cgi?dummy) and sends no-cache >> headers in the HTTP response. There's no way that your browser >> should have shown you the same code again. What is it? >>> There really should be some "are you really a human" at that point -- >> >> What? > > What I meant was that the failure to match error page should give > another (presumably different) image to match so one could continue > the submit process without loss of the information that had just been > manually entered. > > Sort of a "second try". This is a denial of service waiting to happen. Unless, of course, there is a severely limited number of allowed retries; in which case we're back to solving the problem with having just one retry, and the caching misbehavior you're seeing.