461672 - newsgroup filters not working with Astraweb news server

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: NNTP, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

Attachment: 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.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 2

[Joshua Cranmer [:jcranmer]]

(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.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

(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.)

Comment 4

[Wayne Mery (:wsmwk)]

changing to UNCO rather than adding qawanted, since we don't understand yet what this is about

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Why not close it WONTFIX?  Be honest.

Comment 6

[Wayne Mery (:wsmwk)]

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.

Comment 7

[Joshua Cranmer [:jcranmer]]

(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.

Comment 8

[[:Aureliano Buendía]]

According to comment #7, set closeme flag.

Comment 9

[Wayne Mery (:wsmwk)]

ATM there isn't enough information here (ref comment 7), so closing.