Created attachment 344778 [details] annotated nntp log (level 5) for the test SM trunk nightly Gecko/20081004 Today is the last day on which ComCast users get usenet newsgroup service as a bundled part of their cable internet services. Comcast's nntp service had been actually provided by giganews. Knowing the troubles that Mozilla news filters had had with giganews servers, I decided to try a different server. So, I switched to another usenet provider, Astraweb. See http://www.news.astraweb.com/ After setting up my new account and subscribing to the same newsgroups as I had been using with giganews, I copied all my filters over, too. I copied the .dat files over from the directory for the comcast/giganews server to the directory for the astraweb server. Then I did a series of tests, reading newsgroups one at a time, first on the comcast server, then on astraweb. The filtering on the giganews servers worked as it had before, well, but VERY slowly (~3 messages/sec). On Astraweb, there was no evidence that any filtering was taking place at all. The astraweb filter log file remains empty. So, I repeated the test with nntp logging enabled. The annotated log file is attached. It looks like the client sent the command XHDR path 16998-17006 to the server. After that, there are a bunch of lines in the log that say Next state: NNTP_XHDR_RESPONSE but I see no actual data being returned by the server. Do I need to turn the level of nntp logging up past 5 to get all the nntp data? ("Turn it all the way up to 11" ? :) Both servers use SSL, so a packet sniffer won't be helpful, I think.
In case you're wondering, yes, I verified with the UI that the news client does see all the filters for the newsgroups and for the server itself on the new server that it saw on the old server.
(In reply to comment #0) > So, I repeated the test with nntp logging enabled. The annotated log file > is attached. It looks like the client sent the command > XHDR path 16998-17006 > to the server. After that, there are a bunch of lines in the log that say > Next state: NNTP_XHDR_RESPONSE > but I see no actual data being returned by the server. Do I need to turn > the level of nntp logging up past 5 to get all the nntp data? > ("Turn it all the way up to 11" ? :) NNTP logging only logs the first line of responses. > Both servers use SSL, so a packet sniffer won't be helpful, I think. According to http://www.wireshark.org/about.html, Wireshark can look at the SSL packets.
(In reply to comment #2) > NNTP logging only logs the first line of responses. But I don't see ANY lines of XHDR response. Do you? > According to http://www.wireshark.org/about.html, Wireshark can look at > the SSL packets. Oh, yes, I know. I am mozilla's SSL developer after all. It looks at them at a level that may be useful for debugging SSL issues, but we're not having SSL issues here, and it doesn't decrypt the traffic. (It can't. If it could, SSL would be useless.)
changing to UNCO rather than adding qawanted, since we don't understand yet what this is about
Why not close it WONTFIX? Be honest.
for starters, I'm not that devious and I don't have authority to WONTFIX :) If honesty means adding clarity ... I'm following my imperfect understanding of what is written in the comments and fthe definition of NEW/UNCO in https://bugzilla.mozilla.org/page.cgi?id=fields.html#status Why do you suggest WONTFIX? If it's purely a server issue then it's INVALID. Feel free to elaborate.
(In reply to comment #5) > Why not close it WONTFIX? Be honest. Well, you haven't provided enough information, so that would make it an INCO resolution, not WONTFIX. I can't see it, but nor do I have the resources to test it.
According to comment #7, set closeme flag.
ATM there isn't enough information here (ref comment 7), so closing.