Re: Squid3: schedule and naming
> On Tue, 2007-08-07 at 20:22 +1200, Amos Jeffries wrote:
>
>> We are only waiting on two blocker bugs now before 3.0 or PRE7.
>> How soon? and which? I'm just so impatient to know :-)
>
> I think the next release should be RC1, but I do not have a strong
> opinion. It should happen after there are no blockers left. I think
> there has been good progress on both of the existing two blockers, so I
> hope they will be closed this week.
>
> Alex.
>
I just spent the afternoon going over Christos full patch for
squid3-largeobj and only found a few very minor things. Though I still
don't know squid well enough to tell if there is anything missed out.
Christos:
The bits I picked out are below. And feel free to tell me I'm wrong, you
are the expert here.
HttpHdrRange.cc chunk @459
- (uint64_t) looks to be obsolete cast now in the if.
Not sure whether these are needed, but its not clear either way without a
compile test.
peer_digest.cc chunk @787
- (int)
store_dir.cc chunk @330
- (uint64_t )
Some formatting niggles:
access_log.cc chunk @531
- outoff, and dooff definitions are indented with tab, needs to be space.
src/Makefile.am chunk @584
- makefiles are all tab indented. StoreMetaSTDLFS.h has been spaced.
(yes its weird, but I think its a carryover from an automake syntax
requirement)
ufsdump.cc chunk @89
- I would suggest doing a single static_cast in each of your cases and
then using the converted pointer. You will need to add {}. That drops 6
castings down to 2 and makes it more readable.
- Also, anything streamed should not need casting unless its stored wrong
(the "(int)x.getType()" )
not bad for such a large amount of work.
Thank you, most definately.
Amos
Squid3: schedule and naming
On Tue, 2007-08-07 at 20:22 +1200, Amos Jeffries wrote: > We are only waiting on two blocker bugs now before 3.0 or PRE7. > How soon? and which? I'm just so impatient to know :-) I think the next release should be RC1, but I do not have a strong opinion. It should happen after there are no blockers left. I think there has been good progress on both of the existing two blockers, so I hope they will be closed this week. Alex.
Re: Adding custom HTTP headers
On tis, 2007-08-07 at 11:44 +0300, Elmo Todurov wrote: > I want to add a header of my own into all HTTP requests. > > I took the location rewriting code as a template and was quite successful -- > I > can get the data I need, shell it out to an external program and take it back > in. However, I have a hunch that the rewriting/header-adding is called too > late, or something in that spirit. Location rewriting is called in > clientSendMoreHeaderData. location header rewriting is rewriting of a response header, way too late if you want to rewrite some request header. Hooking in at clientRedirectDone is probably a more appropriate place for rewriting request headers in a similar manner. Regards Henrik signature.asc Description: This is a digitally signed message part
Adding custom HTTP headers
I want to add a header of my own into all HTTP requests. I took the location rewriting code as a template and was quite successful -- I can get the data I need, shell it out to an external program and take it back in. However, I have a hunch that the rewriting/header-adding is called too late, or something in that spirit. Location rewriting is called in clientSendMoreHeaderData. Where and how should I stick my code so that it would get called in the right time? Elmo
Re: what about Armenian error pages?
Henrik Nordstrom-5 wrote: > > On tor, 2007-08-02 at 09:09 -0700, Arthur Tumanyan wrote: > >> How do you compare files?What tools do you use? > > Wrote a small perl script for the purpose. It's in the main Squid-2 CVS, > but not published in the tar ball. > > http://wiki.squid-cache.org/CvsInstructions > > Regards > Henrik > > Thanks!I will try as soon as possible. -- View this message in context: http://www.nabble.com/what-about-Armenian-error-pages--tf4102636.html#a12036208 Sent from the Squid - Development mailing list archive at Nabble.com.
Re: squid3-largeobj squid3/src HttpHdrRange.cc...
On tis, 2007-08-07 at 09:48 +0300, Tsantilas Christos wrote: > At the end I just put quick_abort_min and quick_abort_max to its > original behavior. They are storing values in kilobytes and if the units > are missing kilobytes are the default. Ok. > But a problem I am seeing is that at the begging we just want to > simplify the code but now we are talking about correcting others thinks > which are not critical or important. Agreed. However the reason I brought this up was to simplify the code and avoid risks with the typecasts needed in the current code. But it's not a big one. > Any way, it is not difficult to change the above but the original goal > was just to fix the bugs of squid3... I dont know... Either way is fine for me. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: squid3-largeobj squid3/src HttpHdrRange.cc...
Tsantilas Christos wrote: At the end I just put quick_abort_min and quick_abort_max to its original behavior. They are storing values in kilobytes and if the units are missing kilobytes are the default. It is very easy to change it and also is easy to make parser to not require spaces between value and units. But a problem I am seeing is that at the begging we just want to simplify the code but now we are talking about correcting others thinks which are not critical or important. Any way, it is not difficult to change the above but the original goal was just to fix the bugs of squid3... I dont know... Regards, Christos Quite true, Christos. Thanks for the kick. This apparently has been the problem with 3.0 from early on. Far too many 'improvements' popping up. For myself I'm discussing and mostly just keeping an email folder of small ideas for future. When I get my chance at 3.1 a lot will begin to happen. I'm okay with putting the idea on backburner. Right now you are the only one to have put hand to code on this. We are only waiting on two blocker bugs now before 3.0 or PRE7. How soon? and which? I'm just so impatient to know :-) Amos Henrik Nordstrom wrote: On fre, 2007-08-03 at 00:35 +1200, Amos Jeffries wrote: Although having said that, the current parser requires whitespace between the value and the units. I'm not certain that is a good thing. Been like that for ever. Or at least as long as Squid has been parsing units.. i.e. Squid-1.1 or something like that. (1997 timeframe). I don't have a problem having the parser changed so that it also accepts specifications without the space however. Regards Henrik
