https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412014-05-13T16:16:40Zlighty labsLighttpd - Bug #2578: If-None-Match handling does not comply with RFC2616https://redmine.lighttpd.net/issues/2578?journal_id=83732014-05-13T16:16:40Zstbuehler
<ul><li><strong>% Done</strong> changed from <i>90</i> to <i>50</i></li></ul><p>Hi. Thx for your work so far!</p>
<ul>
<li>I wasn't completely happy with the parser and rewrote it a little bit</li>
<li>We usually use tabs to indent</li>
<li>"ISO C90 forbids mixed declarations and code" (http-header-glue.c)</li>
<li>As far as I understand the RFC weak ETag validation must not be used for ranged requests; I therefor had to disable the weak check. Also added a test case for it, and made the two weak cases "TODO" items.</li>
<li>I think the RFC accepts empty "tokens" - skipping <code>","</code> in <code>START</code> should fix it, i.e. <code>If-None-Match: ,"1", ,, "2"</code></li>
<li>Tokens must always be separated by at least one <code>","</code> - <code>TAIL</code> must only go to <code>START</code> with a <code>","</code></li>
<li>I'm not completely sure whether the quoted pairs have to match - is <code>"a"</code> equal to <code>"\a"</code> or not? For now I assume they are not equal: "both validators MUST be identical in every way"</li>
</ul>
<p>See <a class="external" href="http://git.lighttpd.net/lighttpd/lighttpd-1.x.git/commit/?h=lighttpd-1.4.x-stbuehler-if-non-match-2578">http://git.lighttpd.net/lighttpd/lighttpd-1.x.git/commit/?h=lighttpd-1.4.x-stbuehler-if-non-match-2578</a> for my current patch.</p>
<p>I can add your account name + email (or something else) as author if you want.</p>
<p>Any good ideas how to solve the weak ETag validation vs. ranged request thing? Is it really needed? Perhaps <code>etag_is_equal</code> could be extended to return whether it was a strong or a weak match, although I'd like a different function name for that.</p>
Some notes what I changed - maybe you can use the feedback:
<ul>
<li>I think <code>char</code> is a bad substitute for <code>bool</code> - char is a "special" integral type. It certainly saves no memory on the stack, in registers or in function parameters. I used <code>int</code> instead.</li>
<li>Mixed returning of enum values and "boolean" values (<code>!...</code>) - this is wrong. The function names indicates the return value is a boolean, and therefore the returned values should only be <code>0</code> or <code>1</code> (or <code>FALSE</code> / <code>TRUE</code>).</li>
<li>Just directly return on success instead of using a special state (and <code>!state</code> is not very readably - enum values should be compared explicitly, so searching for them is easier)</li>
<li><code>enum { FOUND_TOKEN = 0, START, TOKEN, MAYBE_WEAK, QUOTING, TAIL } states;</code> - unused variable <code>states</code>. Perhaps this was inteded as a typedef (<code>typedef enum {...} states;</code>)?</li>
<li>I like to do comparisions with constant values the other way round, so I don't accidentally assign stuff (<code>if ('"' == *current)</code> instead of <code>if (*current == '"')</code>); your <code>const char*</code> pointers would have prevented assignments too ofc.</li>
<li>We have <code>case</code> labels on the same indentation level as the surrounding switch - that way <code>{</code> and <code>}</code> add and remove always exactly one level.</li>
</ul> Lighttpd - Bug #2578: If-None-Match handling does not comply with RFC2616https://redmine.lighttpd.net/issues/2578?journal_id=85102015-07-05T19:00:04Zstbuehler
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Fixed</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>Applied in changeset r2994.</p>