Closed Bug 89939 Opened 23 years ago Closed 16 years ago

URI-parser fails for news:message-id

Categories

(MailNews Core :: Networking: NNTP, defect)

Product:
MailNews Core
Component:
Networking: NNTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bratell, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

news:3B48D5FC.3030004@sc.rr.com is a normal news-URI, but the URI-parser thinks 
that "news" is a host and 3 the port number. This is because 
ExtractPortFrom returns 3 when it gets "3B48D5FC.3030004@sc.rr.com" as input.

The result was an assertion "missing scheme". Since the only use this time was 
to see if the url was an url (and could be turned into a link in the mail) there 
was no harm.
It looks as if the parser thinks news: URLs should be parsed according to the 
generic URI syntax (<scheme>://<remainder-of-URL>), when in fact news, like 
mailto, uses only the colon.
I believe that news will have to implement their own uri parser to avoid this.  
reassigning to default owner.
Assignee: neeti → sspitzer
Component: Networking → Networking - News
Product: Browser → MailNews
QA Contact: benc → stephend
this is a dup, I think.  accepting until I find it.

we aren't handling news:message-id or news:group urls correctly yet.

news://host/message-id and news://host/group urls do work.
Status: NEW → ASSIGNED
You can probably dupe this into bug 77195.
The :// format is supposed to be used for NNTP, news uses the ":", (more
familiarly used in mailto:).

This requested format is the RFC 1738 format.
*** Bug 87615 has been marked as a duplicate of this bug. ***
The 4xp keyword should be added because with this king of URI, Netscape 4.76
displays the message.


*** Bug 99287 has been marked as a duplicate of this bug. ***
bug 99081 also deals with the uri-parser problem and has a patch. However it
will move news:3B48D5FC.3030004@sc.rr.com to news://3B48D5FC.3030004@sc.rr.com/
as it is done with a nsIURL implementation when it should be based on nsIURI.
news://host/message-id and news://host/group urls *do* work, but they
*shouldn't*! The RFC <http://www.w3.org/Addressing/rfc1738.txt> states quite
clearly:

A news URL takes one of two forms:

      news:<newsgroup-name>
      news:<message-id>
...
A nntp URL take the form:

      nntp://<host>:<port>/<newsgroup-name>/<article-number>
...
Note that while nntp: URLs specify a unique location for the article
resource, most NNTP servers currently on the Internet today are
configured only to allow access from local clients, and thus nntp
URLs do not designate globally accessible resources. Thus, the news:
form of URL is preferred as a way of identifying news articles.




It's really weird. news URLs used internally are basically nntp. nntp URLs often
go to the OS, which in some builds returns Outlook Express?!
the fix for bug 99081 is now checked in, the urlparser no longer fails for such
news urls. However the news <-> nntp issue remains.
*** Bug 108877 has been marked as a duplicate of this bug. ***
Blocks: 61521
Blocks: 108877
I don't think that this bug blocks bug 61521, because in that bug, we can use
nntp: URIs with *hostnames* and msgids, which work already (I think).
No longer blocks: 61521
It seems to me that this bug depends on bug 16343. Of course, the parser could
handle this kind of URI without knowing a default news server, but then we
cannot do anything with this.

pi
Boris 'pi' Piwinger, that's bug 108877.
Depends on: 16343
No longer depends on: 16343
*** Bug 153918 has been marked as a duplicate of this bug. ***
What's the status of this bug ?
Changing summary to something better to find and more descriptive.

Right now, when you click on a news URI nothing happens due to bug 108877. The
problem as described originally, disappeared. Does this mean WFM?

For the problem that news://host should really be nntp://host I sugest to
support both since in practice most people use the incorrect news://host. IOW:
make news: and nntp: identical.

pi
Summary: URI-parser fails for news:3B48D5FC.3030004@sc.rr.com → URI-parser fails for news:message-id
I have to correct my previous remark. It does not work. A slash is appended to
the URL:-( So is this a dupe of bug 77195 as suggested previously?

pi
Doesn't it depend on  112422 ?
Depends on: 112422
No. This is only about understanding the URI, not doing anything with it.
No longer depends on: 112422
Blocks: 11076
No longer blocks: 11076
Product: MailNews → Core
*** Bug 272637 has been marked as a duplicate of this bug. ***
Assignee: sspitzer → nobody
Status: ASSIGNED → NEW
QA Contact: stephend
Note that RFC 3986 has obsoleted RFC 1738.  (See <ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt>.)  

Re comment #12:  In Thunderbird, go to the Folders pane and select a newsgroup.  Get the pull-down context menu (right-click on a PC) and select "Copy Folder Location".  Paste the result in a text editor window.  

For the newsgroup mozilla.dev.extensions on the news.mozilla.org server, the result is <news://news.mozilla.org:119/mozilla.dev.extensions>.  Note that this indicates the news protocol, not the nntp protocol.  Is this a bug in Thunderbird, or is this the appropriate URI?  
Actually, I think we should implement <http://www.karlsruhe.org/rfc/draft-ellermann-news-nntp-uri-05.txt>, making a clear distinction between news: and nntp:. 
(This was planned as an optional part of the SoC project (bug 377250), but will most likely not be attacked due to time constraints.)
A strict implementation of the draft RFC cited in comment #27 means that Thunderbird is in error per my comment #26.  This is addressed in bug #226890 (see comments there starting with 3).    

Note that the draft RFC expires tomorrow.
QA Contact: networking.news
Updated RFC URI. And no, the URI will no longer be invalid per spec.

Anyways, the URI parser doesn't fail with any assertion, so marking WFM.
URL: http://tools.ietf.org/html/draft-elle...
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.