You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Phil Dietz <pe...@west.com> on 1999/01/13 17:37:56 UTC
apache-api/3657: apache returning status 304 on images that are updated
>Number: 3657
>Category: apache-api
>Synopsis: apache returning status 304 on images that are updated
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apache
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Wed Jan 13 08:40:01 PST 1999
>Last-Modified:
>Originator: pedietz@west.com
>Organization:
apache
>Release: 1.3.3 1.3.4
>Environment:
AIX 4.3.2
both cc and gcc
browsers IE4.1, IE5.0 beta, (Netscape4.5 generally works right)
>Description:
A CGI script updates an image and displays it every so often.
He ported his script from Netscape server to apache 1.3.3 yesterday.
His graphics quit updating. The graphic displayed is the initial graphic when he first opened his browser. None of the updates come across.
After snooping with a proxy and later apache source code, it appears the ap_find_token() command is not working correctly.
Internet Explorer 4.1 and 5.0beta browser sends:
If-None-Match: W/"2f30-f20-369bbd06"
apache returns Etag: W/"2f30-11b3-369bd28d"
The two are completely different which jives since the image was updated.
Inside of ap_find_token() (which was called by ap_meets_conditions() in the If-None-Match" section), I put in some debugging code:
/* find http tokens, see the definition of token from RFC2068 */
API_EXPORT(int) ap_find_token(pool *p, const char *line, const char *tok)
{
const unsigned char *start_token;
const unsigned char *s;
if (!line)
return 0;
s = (const unsigned char *)line;
for (;;) {
/* find start of token, skip all stop characters, note NUL
* isn't a token stop, so we don't need to test for it
*/
while (TEST_CHAR(*s, T_HTTP_TOKEN_STOP)) {
++s;
}
if (!*s) {
return 0;
}
start_token = s;
/* find end of the token */
while (*s && !TEST_CHAR(*s, T_HTTP_TOKEN_STOP)) {
++s;
}
DEBUG(123456, "debug: %s, %s, %d\n", start_token, tok, s - start_token);
if (!strncasecmp((const char *)start_token, (const char *)tok, s - start_token)) {
return 1;
}
if (!*s) {
return 0;
}
}
}
A result is:
debug: W/"2f2d-1299-369cbbd9", W/"2f2d-12a5-369cbf5e", 1
Notice the strncasecmp length of 1. That means only the leading W's are being compared, which do match.
Shouldn't the entire string be compared ?
Because the leading W's match, ap_meets_conditions() is sending back a HTTP_NOT_MODIFIED status for my images -- when they have updated.
Any help ?
>How-To-Repeat:
I tested this on both apache1.3.3 and apache1.3.4.
>Fix:
Should the entire ETag: be compared to If-None-Match: or just the leading char ?
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig- ]
[nored unless you are responding to an explicit request ]
[from a developer. ]
[Reply only with text; DO NOT SEND ATTACHMENTS! ]
Re: apache-api/3657: apache returning status 304 on images that are updated
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 20 Jan 1999, Rodent of Unusual Size wrote:
> Phil Dietz wrote:
> >
> > After snooping with a proxy and later apache source code,
> > it appears the ap_find_token() command is not working correctly.
> >
> > Internet Explorer 4.1 and 5.0beta browser sends:
> > If-None-Match: W/"2f30-f20-369bbd06"
> > apache returns Etag: W/"2f30-11b3-369bd28d"
> >
> > The two are completely different which jives since the image was updated.
>
> Hmm. Indeed, the problem appears to be due to '/' being
> considered special for HTTP transforms; in this case,
> specifically by ap_find_token().
>
> It looks like possible solutions include:
>
> 1. Change '/' to not be special for HTTP (change
> gen_test_chars.c).
> 2. Change the weak etag prefix from 'W/' to something else.
> 3. Use some other method than ap_find_token() to locate
> tokens for comparison.
>
> [2] is right out - 'W/' is part of the HTTP spec.
> [3] isn't terrific, since it appears that ap_find_token()
> was created for this express purpose (the only place it's
> used is in http_protocol.c). So [1] looks like the
> easiest solution -- except it depends upon whether
> '/' can ever appear inside a token string. Looking
> at the spec, it appears that this is the correct
> solution, but I'll defer to Roy.
>
> Roy?
This is essentially the same bug I was reporting in PR#2065 -- we don't do
proper HTTP parsing at all. We do something that "almost works". We
should do something that works.
Dean
Re: apache-api/3657: apache returning status 304 on images that are updated
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Phil Dietz wrote:
>
> After snooping with a proxy and later apache source code,
> it appears the ap_find_token() command is not working correctly.
>
> Internet Explorer 4.1 and 5.0beta browser sends:
> If-None-Match: W/"2f30-f20-369bbd06"
> apache returns Etag: W/"2f30-11b3-369bd28d"
>
> The two are completely different which jives since the image was updated.
Hmm. Indeed, the problem appears to be due to '/' being
considered special for HTTP transforms; in this case,
specifically by ap_find_token().
It looks like possible solutions include:
1. Change '/' to not be special for HTTP (change
gen_test_chars.c).
2. Change the weak etag prefix from 'W/' to something else.
3. Use some other method than ap_find_token() to locate
tokens for comparison.
[2] is right out - 'W/' is part of the HTTP spec.
[3] isn't terrific, since it appears that ap_find_token()
was created for this express purpose (the only place it's
used is in http_protocol.c). So [1] looks like the
easiest solution -- except it depends upon whether
'/' can ever appear inside a token string. Looking
at the spec, it appears that this is the correct
solution, but I'll defer to Roy.
Roy?
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>