It does not work well in Firefox 23.0.1

[GoogleCodeExporter]

Try to use Kaptcha in Firefox 23.0.1, sometimes displaying image is different 
with the one found in response in FireBug, which would result in constantly 
failure.
--The reason is that the servlet is called twice and the value in session is 
updated, while the image remains unchanged.

Original issue reported on code.google.com by awoo1...@gmail.com on 10 Oct 2013 at 4:43

Attachments:

• screenshot.bmp

[GoogleCodeExporter]

Could anyone kindly help on this?

Original comment by awoo1...@gmail.com on 10 Oct 2013 at 4:45

[GoogleCodeExporter]

Could it be that firebug is making multiple requests?

Original comment by latch...@gmail.com on 10 Oct 2013 at 2:35

[GoogleCodeExporter]

The problem does exist. Kaptcha in Firefox doesn't refresh correctly for an 
unknown reason (Safari, Chrome and MSIE doesn't have this problem).

Original comment by ilya.obs...@gmail.com on 20 Jan 2014 at 11:16

[GoogleCodeExporter]

Sweet, when you know what the problem is, let me know and I'll try to fix the 
code.

Original comment by latch...@gmail.com on 20 Jan 2014 at 11:31

[GoogleCodeExporter]

After doing some reverse engineering it turns out that the calling framework 
(Tapestry in my case) is responsible for the issue. However, others may 
encounter it as well because Firefox probably uses a different image caching 
algorithm which results in skipping image loading without any respect to cache 
headers.

So this is definitely a Firefox bug (not Tapestry). As a workaround I would 
suggest ALWAYS adding random query string, like <img 
src="captcha_image.png?random=738572"/>.

Original comment by ilya.obs...@gmail.com on 21 Jan 2014 at 1:50

[GoogleCodeExporter]

That sounds more like an issue with Tapestry than with Kaptcha.

Original comment by latch...@gmail.com on 21 Jan 2014 at 6:23

[GoogleCodeExporter]

Like I said, it's not a Tapestry (or any other surrounding framework) error. 
Tapestry does everything correctly (i.e. renders the necessary img tag). The 
problem is with Firefox and Firefox only (for some reason it doesn't reload the 
image).

Original comment by ilya.obs...@gmail.com on 21 Jan 2014 at 10:11

[GoogleCodeExporter]

It is a problem if tapestry sets the outgoing cache headers.

Original comment by latch...@gmail.com on 21 Jan 2014 at 10:32

[GoogleCodeExporter]

Tapestry does so before sending the actual image:

        response.setDateHeader("Expires", 0);
        // Set standard HTTP/1.1 no-cache headers.
        response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate");
        // Set IE extended HTTP/1.1 no-cache headers (use addHeader).
        response.setHeader("Cache-Control", "post-check=0, pre-check=0");
        // Set standard HTTP/1.0 no-cache header.
        response.setHeader("Pragma", "no-cache");

It looks correct: Tapestry instructs browser to never cache the image.

Original comment by ilya.obs...@gmail.com on 21 Jan 2014 at 10:37

[GoogleCodeExporter]

Calling setHeader 2x for the same header seems pretty darn broken to me. The 
second one is overwriting the value of the first one and the first one is 
actually the important one. What's up with the (use addHeader) comment?

http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#
setHeader(java.lang.String, java.lang.String)

"If the header had already been set, the new value overwrites the previous one."

Here is how the KaptchaServlet does it:

https://code.google.com/p/kaptcha/source/browse/trunk/src/java/com/google/code/k
aptcha/servlet/KaptchaServlet.java#72

Cheers.

Original comment by latch...@gmail.com on 22 Jan 2014 at 1:39

[GoogleCodeExporter]

Well, ugh. You are right. I've overlooked the second call to setHeader(). 

Tapestry response object is a thin wrapper above HttpServletResponse. But it 
doesn't expose the latter's addHeader() method (that's what they probably mean 
in comment). 

Probably other browsers are satisfied with Expires: 0, that's why everything 
works except Firefox.

Original comment by ilya.obs...@gmail.com on 22 Jan 2014 at 1:49

[GoogleCodeExporter]

Sigh.

Original comment by latch...@gmail.com on 22 Jan 2014 at 1:51