<div>Ok, on further observation this is a Chrome error and not an Nginx error. There is no real difference between my gif and yours, only happened to forget to load mine which is why it displayed correctly in the specific block (it was actually empty!). The bug renders the background with 1 less brightness on all channels, so #FFFFFF becomes #FEFEFE and #443631 becomes #433530, etc. Attached a screenshot even though it&#39;s really not your problem anymore. I&#39;ll report be reporting this to the Chromium developers, you can rest easy about this.</div>

<div><br></div><div>Now I&#39;m curious to know what color #256 would render as, probably something odd from outside the buffer :)</div><div><br><div class="gmail_quote">On Thu, Jul 1, 2010 at 4:00 AM,  <span dir="ltr">&lt;<a href="mailto:nginx-request@nginx.org">nginx-request@nginx.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Send nginx mailing list submissions to<br>
        <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://nginx.org/mailman/listinfo/nginx" target="_blank">http://nginx.org/mailman/listinfo/nginx</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
        <a href="mailto:nginx-request@nginx.org">nginx-request@nginx.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:nginx-owner@nginx.org">nginx-owner@nginx.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of nginx digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
   1. Re: how to deny the SSL v2.0 handshake when SSL v2.0 is<br>
      disabled (Igor Sysoev)<br>
   2. Empty GIF generator not actually empty (Lorin Halpert)<br>
   3. Re: Empty GIF generator not actually empty (Igor Sysoev)<br>
   4. Re: Empty GIF generator not actually empty (Igor Sysoev)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 1 Jul 2010 09:26:10 +0400<br>
From: Igor Sysoev &lt;<a href="mailto:igor@sysoev.ru">igor@sysoev.ru</a>&gt;<br>
To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Re: how to deny the SSL v2.0 handshake when SSL v2.0 is<br>
        disabled<br>
Message-ID: &lt;<a href="mailto:20100701052610.GA36735@rambler-co.ru">20100701052610.GA36735@rambler-co.ru</a>&gt;<br>
Content-Type: text/plain; charset=koi8-r<br>
<br>
On Wed, Jun 30, 2010 at 04:21:25PM -0400, Calomel Org wrote:<br>
<br>
&gt; Is there any way to completely disable the SSL v2.0 handshake when SSL<br>
&gt; v2.0 support is disabled in nginx.conf ?<br>
&gt;<br>
&gt; This is the SSL configuration used and only TLSv1 is enabled in<br>
&gt; &quot;ssl_protocols&quot;.<br>
&gt;<br>
&gt;   ## Nginx SSL (FIPS 140-2 experimental)<br>
&gt;    ssl on;<br>
&gt;    ssl_certificate /ssl_keys/host.org_ssl.crt;<br>
&gt;    ssl_certificate_key /ssl_keys/host_ssl.key;<br>
&gt;    ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA;<br>
&gt;    ssl_dhparam /ssl_keys/host_dh.pem;<br>
&gt;    ssl_prefer_server_ciphers on;<br>
&gt;    ssl_protocols TLSv1;<br>
&gt;    ssl_session_cache shared:SSL:10m;<br>
&gt;    ssl_session_timeout 5m;<br>
&gt;<br>
&gt; The reason this question has come up is SSL Labs has recently been in<br>
&gt; the news promoting a tool to check the compliance of a SSL server. We<br>
&gt; thought we would check our host and we ranked at the very top (93%) of<br>
&gt; the &quot;Recent Best-Rated&quot;. The testing site can be found here:<br>
&gt;<br>
&gt;   <a href="https://www.ssllabs.com/ssldb/index.html" target="_blank">https://www.ssllabs.com/ssldb/index.html</a><br>
&gt;<br>
&gt; When we checked our server (<a href="https://calomel.org" target="_blank">https://calomel.org</a>) with their tool it<br>
&gt; reported &quot;SSL 2.0+ Upgrade Support&quot; was enabled. We used the OpenSSL<br>
&gt; binary on the command line and found SSLv2 and SSLv3 are definitely<br>
&gt; turned off as Nginx denied the use of these protocols. Only TLSv1 was<br>
&gt; allowed.<br>
&gt;<br>
&gt; The problem is the SSLv2 upgrade support handshake is somehow accepted<br>
&gt; according to SSL Labs. I am not sure how to verify this handshake<br>
&gt; myself.<br>
&gt;<br>
&gt; According to SSL Labs &quot;SSL 2.0+ Upgrade Support&quot; means, &quot;...the server<br>
&gt; supports SSLv2 handshake, even though it may not support SSLv2 itself.<br>
&gt; Essentially it&#39;s an optimization. Instead of a client first requesting<br>
&gt; SSLv2 (with a SSLv2 handshake) and failing (if the server does not<br>
&gt; support it), then having to request SSLv3 or better (with a SSLv3<br>
&gt; handshake), the client can use the SSLv2 handshake to indicate support<br>
&gt; for newer protocols.&quot; The full news group thread containing this quote<br>
&gt; can be found at:<br>
&gt;<br>
&gt;   <a href="http://sourceforge.net/mailarchive/forum.php?thread_name=20100629171623.43012oj4b2hgrzi8%40webmail.mxes.net&amp;forum_name=ssllabs-discuss" target="_blank">http://sourceforge.net/mailarchive/forum.php?thread_name=20100629171623.43012oj4b2hgrzi8%40webmail.mxes.net&amp;forum_name=ssllabs-discuss</a><br>


&gt;<br>
&gt; Lastly, in order for a server to be considered &quot;FIPS 140-2 Compliant&quot;<br>
&gt; it must not respond to any SSLv2 or SSLv3 protocol requests. Only<br>
&gt; TLSv1 (version 1.0 to 1.2) are accepted.<br>
&gt;<br>
&gt; We appreciate any help, suggestions or clarification.<br>
<br>
As I understand OpenSSL sources it disables SSL 2.0+ upgrade support,<br>
only if FIPS is enabled. If you built OpenSSL with FIPS support,<br>
then add in openssl.cnf:<br>
<br>
openssl_conf = openssl_options<br>
<br>
[ openssl_options ]<br>
alg_section = algs<br>
<br>
[ algs ]<br>
fips_mode = yes<br>
<br>
<br>
--<br>
Igor Sysoev<br>
<a href="http://sysoev.ru/en/" target="_blank">http://sysoev.ru/en/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 1 Jul 2010 01:48:31 -0400<br>
From: Lorin Halpert &lt;<a href="mailto:alystair@gmail.com">alystair@gmail.com</a>&gt;<br>
To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Empty GIF generator not actually empty<br>
Message-ID:<br>
        &lt;<a href="mailto:AANLkTilLCj8oYeQKPiVmc0OFT0717hKVAhQkV2onVD4i@mail.gmail.com">AANLkTilLCj8oYeQKPiVmc0OFT0717hKVAhQkV2onVD4i@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<br>
<br>
Using the built-in generator changes the color of the background color under<br>
Chrome, yet using my own blank doesn&#39;t cause this. I&#39;ve attached a &quot;known<br>
good&quot; blank created in Fireworks (same byte size) so it can replace the one<br>
in the nginx codebase. I am under windows with no development tools so I<br>
can&#39;t create a patch myself but I&#39;m able to test a new binary to validate<br>
that it&#39;s fixed.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://nginx.org/pipermail/nginx/attachments/20100701/d0cf4e89/attachment-0001.html" target="_blank">http://nginx.org/pipermail/nginx/attachments/20100701/d0cf4e89/attachment-0001.html</a>&gt;<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: b.gif<br>
Type: image/gif<br>
Size: 43 bytes<br>
Desc: not available<br>
URL: &lt;<a href="http://nginx.org/pipermail/nginx/attachments/20100701/d0cf4e89/attachment-0001.gif" target="_blank">http://nginx.org/pipermail/nginx/attachments/20100701/d0cf4e89/attachment-0001.gif</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 1 Jul 2010 10:23:14 +0400<br>
From: Igor Sysoev &lt;<a href="mailto:igor@sysoev.ru">igor@sysoev.ru</a>&gt;<br>
To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Re: Empty GIF generator not actually empty<br>
Message-ID: &lt;<a href="mailto:20100701062314.GE36735@rambler-co.ru">20100701062314.GE36735@rambler-co.ru</a>&gt;<br>
Content-Type: text/plain; charset=koi8-r<br>
<br>
On Thu, Jul 01, 2010 at 01:48:31AM -0400, Lorin Halpert wrote:<br>
<br>
&gt; Using the built-in generator changes the color of the background color under<br>
&gt; Chrome, yet using my own blank doesn&#39;t cause this. I&#39;ve attached a &quot;known<br>
&gt; good&quot; blank created in Fireworks (same byte size) so it can replace the one<br>
&gt; in the nginx codebase. I am under windows with no development tools so I<br>
&gt; can&#39;t create a patch myself but I&#39;m able to test a new binary to validate<br>
&gt; that it&#39;s fixed.<br>
<br>
The current empty GIF has 2 colors: #0: black and #1 white.<br>
The white (#1) color is used as background and as transparent color.<br>
<br>
The suggested GIF has two colors: #0 gray (C0C0C0) and #1 black.<br>
The transparent color is #0 (gray). The background color is #256<br>
and there is no such color number in the GIF table. I&#39;m not sure<br>
how browsers will handle this case. Probably they use just #1 color.<br>
<br>
However, I do not understand the issue. Could you show example on<br>
the web where built-in GIF changes background color ?<br>
<br>
<br>
--<br>
Igor Sysoev<br>
<a href="http://sysoev.ru/en/" target="_blank">http://sysoev.ru/en/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 1 Jul 2010 10:24:50 +0400<br>
From: Igor Sysoev &lt;<a href="mailto:igor@sysoev.ru">igor@sysoev.ru</a>&gt;<br>
To: <a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
Subject: Re: Empty GIF generator not actually empty<br>
Message-ID: &lt;<a href="mailto:20100701062450.GF36735@rambler-co.ru">20100701062450.GF36735@rambler-co.ru</a>&gt;<br>
Content-Type: text/plain; charset=koi8-r<br>
<br>
On Thu, Jul 01, 2010 at 10:23:14AM +0400, Igor Sysoev wrote:<br>
<br>
&gt; On Thu, Jul 01, 2010 at 01:48:31AM -0400, Lorin Halpert wrote:<br>
&gt;<br>
&gt; &gt; Using the built-in generator changes the color of the background color under<br>
&gt; &gt; Chrome, yet using my own blank doesn&#39;t cause this. I&#39;ve attached a &quot;known<br>
&gt; &gt; good&quot; blank created in Fireworks (same byte size) so it can replace the one<br>
&gt; &gt; in the nginx codebase. I am under windows with no development tools so I<br>
&gt; &gt; can&#39;t create a patch myself but I&#39;m able to test a new binary to validate<br>
&gt; &gt; that it&#39;s fixed.<br>
&gt;<br>
&gt; The current empty GIF has 2 colors: #0: black and #1 white.<br>
&gt; The white (#1) color is used as background and as transparent color.<br>
&gt;<br>
&gt; The suggested GIF has two colors: #0 gray (C0C0C0) and #1 black.<br>
&gt; The transparent color is #0 (gray). The background color is #256<br>
<br>
The background color is #255 ...<br>
<br>
&gt; and there is no such color number in the GIF table. I&#39;m not sure<br>
&gt; how browsers will handle this case. Probably they use just #1 color.<br>
&gt;<br>
&gt; However, I do not understand the issue. Could you show example on<br>
&gt; the web where built-in GIF changes background color ?<br>
<br>
<br>
--<br>
Igor Sysoev<br>
<a href="http://sysoev.ru/en/" target="_blank">http://sysoev.ru/en/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://nginx.org/mailman/listinfo/nginx" target="_blank">http://nginx.org/mailman/listinfo/nginx</a><br>
<br>
<br>
End of nginx Digest, Vol 9, Issue 2<br>
***********************************<br>
</blockquote></div><br></div>