Case-insensitive parsing of <id-right> in message-IDs

Julien ÉLIE julien at trigofacile.com
Fri Aug 5 20:48:22 UTC 2011


Hi Russ,

I am answering to an old message (December 2009) because someone has 
just asked me why his 'XPAT References' calls are failing when the 
message-ID that he looks up contains uppercase characters.
He notes that when replacing the uppercase chars with '*', INN finds the 
article.

This bug reminds me of this discussion…


>> Couldn't we change the code of HashMessageID() to always return the
>> case-sensitive hash and, in case the given message-ID was found to be
>> case-insensitively parsed, we add a new entry to the history database
>> with the case-sensitive hash, if it does not exist yet, (with the same
>> information as the case-insensitive one) and we replace the
>> case-insensitive entry with NULL information so that is will be expired
>> the next time expire runs?
>
> Ah, yes, that would work.
>
>> We have to check whether that behaviour can be done every time the
>> HashMessageID() is called.
>
> It might slow us down a little bit, since we have to check both the
> case-sensitive and case-insensitive hashes for every hash miss, so at some
> point we'll want to stop doing it.  Hard to know when it's safe to stop,
> though.

A suggestion:

   - make INN 2.6.0 use case-sensitive hashes;

   - provide a script that retrieves every token (from the history 
file), parses the related article to find out its message-ID, and does 
the relevant actions if it contains uppercase characters:  run 
prunehistory on the wrong message-ID and run ctlinnd addhist with the 
appropriate arguments (in particular, the right message-ID);

   - ask in our release notes to run this script once, right after the 
upgrade or after a run of news.daily.


Maybe the actions could also be integrated in expire, and therefore 
directly writing the new history file in the right format.  We should 
find a way to do the check only once, though.  Maybe by putting an 
"expire.dohistconvertcase" file in pathlog at the end of a make update. 
  If present, expire does that and removes the file.
Yet, it will do that after every update.  Perhaps not a big deal for 
official releases.  It is more problematic for people who frequently 
update from STABLE or CURRENT.

The main point would be to automatically do the process, in case an 
administrator does not see that he should run an external command or add 
any flag to news.daily, etc.


What do you think about that plan?  Would you recommend another strategy?
I do believe it is something that should be fixed in INN 2.6.0 (or 
earlier if the transition is smooth).

-- 
Julien ÉLIE

« En France, on n'a pas de pétrole, mais on a des idées ! Alors,
   j'ai troqué ma deux-chevaux contre une deux-bœufs ! » (Raymond
   Devos)



More information about the inn-workers mailing list