Possible memory fault in pinger
Hi,
Squid 2.5 and Squid 3
file pinger.c/pinger.cc, function pingerSendEcho()
1)
I have
//MAX_PKT_SZ=294, sizeof(pkt)=294, sizeof(struct
icmhdr)=28,sizeof(icmpEchoData)=268,
//28+268=296 > 294!
so it is possible to have a big problem in/with xmemcpy
if (payload) {
if (len > MAX_PAYLOAD)
len = MAX_PAYLOAD;
xmemcpy(echo->payload, payload, len);
Can we write beyond pkt array and just to icmp pointer ?
It seems that we can and the code should be corrected in some way
2) Just look at Squid3 and a number versions of v2.xx
in 2.5 we have
icmp_pktsize += sizeof(struct timeval) + sizeof(char);
In 3.0 and 2.4
icmp_pktsize += sizeof(icmpEchoData) - MAX_PAYLOAD;
definitly that with different stucture alingment we will have differet
values for icmp_pktsize in both cases, so what is right ?
SY,
Evgeny Kotsuba
Re: ETag support
> > ii. function httpReplyValidatorsMatch(). > > > > It is called when server responded with 304 Not Modified and squid > > decides whether to pass this 304 to requesting client, or to return old > > cached entry... to be more exact there is an if: > >if (!httpReplyValidatorsMatch(.. > > we analised the code and we think there is no possibility that in thath > > place this function would return false... is it true? > > Hmm.. in what function? There is many such ifs with somewhat different > purpose. sorry... I wasn't looking at the source whlie writing this mail and i hoped the question wouldn't be ambiguous... apparently i was wrong... its in clientReplyContext::clientGetsOldEntry() in client_side_reply.cc thx for other answers they will help us :), Mati.
Re: ETag support
On Thu, 15 Apr 2004, Mateusz Srebrny wrote: > Hi, > > As we go on with our project some new questions regarding the code arose. > > i. the function cacheHit. > > We need to know when this function is called. I mean, it seems it is > called in two cases: firstly when the entry client requested is found in > the store snd squid has to decide what to do with it, and secondly, when > client request was passed to the origin server and new entry is also in > store and squid again has to decide what to return to requesting client. > > Is that all? Sounds correct. cacheHit is called to parse header data as it is being read in, and it is this function which knows when the reply heaers have been fully seen. In future it is planned to have this redone to split headers from the payload, an pass around a already parsed reply header. > There is some IMS mathcing so we figured it is good place to add ETag > matching, and we want to know what can we assume on its flow context... In principle where there is IMS matching ETag matching of this object also belongs. There may be one or two special cases, but not much. > ii. function httpReplyValidatorsMatch(). > > It is called when server responded with 304 Not Modified and squid > decides whether to pass this 304 to requesting client, or to return old > cached entry... to be more exact there is an if: > if (!httpReplyValidatorsMatch(.. > we analised the code and we think there is no possibility that in thath > place this function would return false... is it true? Hmm.. in what function? There is many such ifs with somewhat different purpose. > iii. let's say a client's request contains an If-Modified-Since header > and squid has no matching entry so it has to pass the request to origin > server... currently it passes the request with the IMS. Yes. > is it correct? Doubtful, but it is a thin line. Not forwarding the IMS on objects not in the cache gives more predictable and stable results, but at the same time may significantly reduce the local browser cache hit ratio.. > mean when server responds 304 squid won't be able to > cache the response... Correct. In the simple world before Vary, If-None-Match etc these actually could have been cached but we never got to it. Now with the more expressive HTTP/1.1 validators 304 can no longer be cached, as it is impossible to tell from the 304 reply alone which entity it belongs to or if there is variance or not.. So for future it is probably best to not forward validators when nothing is known about the object if we thing the reply may be cacheable. But then we also risk breaking some applications which assumes cache validators is end-to-end.. > ok... we think that full ETag support is also very powerful for the users > even wihout vary. Indeed. The ETag based cache validators is very useful in guaranteeing consistent results. > but we try to support vary anyway. > Currently we have about a half of ETag support implemented. Sounds great! > In a week or two we'll have it finished and then we'll go for the vary :D That will be an interesting experience involving many parts of Squid.. > and regarding documentation. > we eventually found it in doc/programming-guide, > but a quick glance on it suggests that places of our interests, ie > client_side*, are not documented better than in squid 2.5... Sorry to hear that. Should be a sign that it is still working more or less in the same manner except for the C++ translation. > Anyway we collect our experiences with the code and after the vary > implementetion we will be able to contribute to the documentation also. Sounds even better!
Re: ETag support
Hi, As we go on with our project some new questions regarding the code arose. i. the function cacheHit. We need to know when this function is called. I mean, it seems it is called in two cases: firstly when the entry client requested is found in the store snd squid has to decide what to do with it, and secondly, when client request was passed to the origin server and new entry is also in store and squid again has to decide what to return to requesting client. Is that all? There is some IMS mathcing so we figured it is good place to add ETag matching, and we want to know what can we assume on its flow context... ii. function httpReplyValidatorsMatch(). It is called when server responded with 304 Not Modified and squid decides whether to pass this 304 to requesting client, or to return old cached entry... to be more exact there is an if: if (!httpReplyValidatorsMatch(.. we analised the code and we think there is no possibility that in thath place this function would return false... is it true? iii. let's say a client's request contains an If-Modified-Since header and squid has no matching entry so it has to pass the request to origin server... currently it passes the request with the IMS. is it correct? I mean when server responds 304 squid won't be able to cache the response... ok... these are our questions. > And regarding Vary... the two go intimately together. There is not very > much value in implementing ETag if not having Vary using it.. If all you > want it to implement the missing ETag functionality with no respect to > Vary then the patch is basically not needed. The bulk of the patch > implements the Vary+ETag combo. ok... we think that full ETag support is also very powerful for the users even wihout vary. but we try to support vary anyway. Currently we have about a half of ETag support implemented. In a week or two we'll have it finished and then we'll go for the vary :D and regarding documentation. we eventually found it in doc/programming-guide, but a quick glance on it suggests that places of our interests, ie client_side*, are not documented better than in squid 2.5... Anyway we collect our experiences with the code and after the vary implementetion we will be able to contribute to the documentation also. Regards, Mati.
Re: commit notices from my squid arch archive
On Thu, 15 Apr 2004, Robert Collins wrote: > Could we move it onto the squid server perhaps? > [EMAIL PROTECTED], and document it on the squid-cache > website? I don't see any problem with this. Regards Henrik
