39376 - Implement versions of nsEscape et. al. that take PRUnichars

Status: RESOLVED INVALID

(Core :: XPCOM, defect, P3)

Description

[Chris Waterson]

...or nsStrings or somesuch.

Comment 1

[Chris Waterson]

I need this so I can re-write the nsHTTPIndex parser to be wide-string 
compliant.

Comment 2

[Robert John Churchill]

Adding nsbeta2 to the keywords line for this bug as bug # 28787 (which depends 
upon this one) is already nsbeta2+.

Comment 3

[leger]

Putting on [nsbeta2+] radar.

Comment 4

[Scott Collins]

I'm working on this stuff right now.  I'll be putting this with other conversion 
routines that waterson and I discussed.  I'll have this done by Thursday the 6th 
and I'm updating the status whiteboard to reflect that.

Comment 5

[Scott Collins]

OK, two problems:

  (1) the existing |nsEscape| stuff is not as re-usable as I had hoped...

  (2) I can make this stuff work with strings from the string hierarchy, but
      the escape stuff really shouldn't be made to work on wide characters.
      Certainly, the current table approach would no longer be appropriate.
      But this escape scheme is really all about ASCII (see RFC 1738).  I can
      make this work on our UCS2 (or whatever it is) strings, but pretending
      they are just ASCII.  I mean think about it... any unicode character
      outside the ASCII range would require 4 digits to encode, and that's not
      in the spec.

I have to move out the ETA a little.  But what is the answer to (2), above?  
Chris?  The only reason you could want this is because you want to work on 
ostensibly ASCII strings that have been `widened' for some API expecting
|PRUnichar|s.  If _that's_ the case, then this might be the wrong approach to 
fixing the problem.  The right approach would be to fix the chain of passing 
these things around to keep then narrow longer.  This escape stuff is only 
appropriate for URLs ... which are supposed to be only (a small subset of) ASCII.  
I know we've been having a debate about this, because somehow they got stored as 
wide strings.

Are we really trying to put the fix in the right place?

Comment 6

[Chris Waterson]

Hrm. I'm now wondering if this bug was misguided. Since rjc is now working on
28787, you may want to ask him if he really needs this. I think he's changed the
file system parsing code to actually go directly to the file system rather than
through the nsHTTPIndex stream, so he may just be using nsIFile and
automagically get the platform encoding and stuff.

Comment 7

[Robert John Churchill]

Bug # 28787 should probably refer strictly to FTP issues, so the nsEscape issue 
is still valid to some degree, unfortunately.

Isn't the FTP code in Necko is sending UTF-8 ?

Comment 8

[Scott Collins]

This is a valid bug, yes, bug probably not an nsbeta2+ bug.  This is really 
only a request for a shortcut, since equivalent functionality exists: convert 
string to ASCII, escape it.  This bug is really a feature request for a 
shortcut, at its heart.  I recommend making this bug not be nsbeta2+.  Plus, I 
still think the solution is wrong on its face and I want to talk you out of 
it.  Removing ETA (the MS conference has pretty effectively cut me off all 
week) and recommending making this bug be not nsbeta2+.

Comment 9

[leger]

Per today's PDT mtg, moving from [nsbeta2+] to [nsbeta2-]

Scott...you are a wise man :-)

Comment 10

[Scott Collins]

OK, I think this bug is wrong on its face; and nobody is pushing hard against 
that, so I'm now going to mark it invalid (see earlier comments for why).  If you 
disagree, you know what to do :-)