Open Bug 136256 Opened 22 years ago Updated 2 years ago

Unable to open folder access rules window for non-ASCII IMAP folders on 4.x servers

Categories

(MailNews Core :: Internationalization, defect)

Product:
MailNews Core
Component:
Internationalization
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED
Milestone:
mozilla1.0

People

(Reporter: ji, Unassigned)

References

Details

(Keywords: intl) 

With the current build which supports IMAP shared folder, I can open folder 
access rules window for ASCII imap folders, but i'm unable to open the window 
for non-ASCII folders.
Steps to reproduce:
1. Have a non-ASCII folder in IMAP account.
2. Select the non-ascii folder and open the folder property window for it.
3. Click on Sharing tab
4. click on Privileges button, it doesn't open the access rules window, browser 
window keeps on trying forever.
On one of my testing accounts ji3@seamonkey.mcom.com
I have a non-ascii folder tëst, when I open access rules window for this folder,
the browser window goes to 
http://ji3@seamonkey.mcom.com:33333/bin/user/admin/bin/mailaclbody.cgi?folder=user/ji3/t%26AOs-st
Keywords: intl
nominating for nsbeta1.
Keywords: nsbeta1
it looks like we're using the imap mod-utf7 folder name, which is what I would
tink the server wants. I'd check with the admin server people to see how they
want the admin urls encoded.
UTF-8 has to be used according to RFC 2192.

http://www.ietf.org/rfc/rfc2192.txt
> 9. Multinational Considerations
> 
>      IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding
>      non-US-ASCII characters in IMAP mailbox names.  Because this
>      convention is private to IMAP, it is necessary to convert IMAP's
>      encoding to one that can be more easily interpreted by a URL
>      display program.  For this reason, IMAP's modified UTF-7 encoding
>      for mailboxes MUST be converted to UTF-8 [UTF8].  Since 8-bit
>      characters are not permitted in URLs, the UTF-8 characters are
>      encoded as required by the URL specification [BASIC-URL].  Sample
>      code is included in Appendix A to demonstrate this conversion.

cc to taka
reassign to putterman
Assignee: nhotta → putterman
taking
Assignee: putterman → bienvenu
Discussed in Mail News bug mtg with Engineering QA and PjM.  Decided to ADT2 and
plus this bug.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT2]
Target Milestone: --- → mozilla1.0
actually, we're just running the url we get back from the server, so this really
should be up to the server.
Can you try this with 4.x? I strongly suspect this is a problem on the server,
since, as I said before, we just turn around and run the url the server gives us.
4.x doesn't have this problem. It can open the privileges window for non-ASCII
folders.
do you mean non 7-bit ascii? I have a folder with lots of 8 bit character names
that I can launch the admin ui through privileges in Mozilla (the same folder
doesn't work at all in 4.x - I can't even select it). If you could tell me how
to create a folder with a name that doesn't work, or point me at a test account,
I could start debugging this. (your url doesn't work at all for me in 4.x or
Mozilla) However, since all the mail code is doing is running an http url given
to us by the server, there's not going to be anything I can do in my code. 
There might be a browser problem, or a necko problem, but it's really just
pass-through code as far as the imap code is concerned.
Sorry, I should have explained in more details.
Please use the testing account below:
sever name: seamonkey.mcom.com
usrid: ji3
passwd: ji3

I have tëst folder on this account, or you can create a non 7-bit folder by 
copy/paste a  French or German string from website. 
On 4.x, the URL is not working, but I can go to the end user page at
 http://seamonkey.mcom.com:33333/bin/user/admin/bin/enduser
and set folder permissions from there.

On Mozilla, it doesn't show this enduser url, the browser is just trying to open 
the url, so the user can't get around the url problem.
Since the url itself doesn't seem to be working even on 4.x, it does look like a 
server problem.
This problem was seen with 4.x Messenger server.
With 6.0 server, the UI at server side is changed, and I don't see this problem with the new version of the server.
Summary: Unable to open folder access rules window for non-ASCII IMAP folders → Unable to open folder access rules window for non-ASCII IMAP folders on 4.x servers
this is a browser bug - we need to find someone on the browser side to handle this.
Rick, can you give me some hints here? We're running a url given to us by the
mail server - we get challenged for a user name+password, and after I enter
that, we start running the url in a new browser window, but it just spins and spins.

My suspicion is that the server is redirecting us, and this redirection fails
because we ran the url in our mail window doc shell with this line of code:
        rv = docShell->LoadURI(uri, nsnull,
nsIWebNavigation::LOAD_FLAGS_IS_LINK, PR_FALSE);

I tried passing in PR_TRUE for the firstParty parameter and that didn't work
either (not that I know what the firstParty parameter means). I also discovered
that clicking on this url in a mail message works, so there must be something
about the docshell call that isn't right (or some magic that happens when you
click on a link...)

If we stop the url in the browser window and then just hit return in the url bar
to rerun the url, it works fine.
This can't be an ATD2 bug for the mail client since it's a 4.x Mail server bug,
right? Yes, the redirect should succeed and display the server error page, but
even if it does, the mail server is just going to display an error page saying
it can't find the folder since it's not dealing with the same url it gave the
client (this works in 6.x server)
making nsbeta1- since even if we made it show the error page the user still
couldn't do anything when using a 4.x server.
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [ADT2]
iqa: do you agree with the decision?
*** Bug 139854 has been marked as a duplicate of this bug. ***
I think we can provide the end user URL on the error msg page as Communicator
4.x does, so the user can go to that page to set privileges for non-ascii IMAP
folders, a workaround for this problem.
Well, this is not working for 6.0 server either, as far as I18N's concerned.
1.0RC1 sends folder name in modified UTF-7 encoding without specifying charset
using 'charset=' argument in URL.  In WMAP, it's expected to use 'charset=" to
specify charset for embedded string in URL when it's beyond US-ASCII.  It's okay
to use modified UTF-7 for folder name as far as it's URL safe and given with
appropriate 'charset=' argument.

Never mind.  I've got a fix on server side for 6.x releases.
hey david,

i can't think of any good reasons why the call to LoadURI(...) should fail for
your docshell...

my only thought is that 'maybe' it has to do with EventQueues :-(  

I could imagine things wouldn't work 'quite right' if a new browser window was
created while mozilla was sitting inside of a modal event loop for the password
auth dialog...

i think that the 'current event queue' gets cached in a couple of places...  so,
this cached queue would be wrong... and 'possibly' events wouldn't get
dispatched correctly...

does this sound plausible?? or am i just babbling again...  this is the only
senario i can come up with...

-- rick
Rick, that's plausible. There are enough goofy things going on that event queues
might be involved. Maybe I'll try running the url *after* the property dialog is
dismissed and see if that works, if so, it would point at the modal dialog and
not the way I'm running the url.
can't reproduce on 2002-06-14-08-1.0.0
Windows XP pro. JA & Mac OS 9.1 JA
Product: MailNews → Core
Gary, see this?
Product: Core → MailNews Core
 :Bienvenu I think everyone here is gone

 :Bienvenu in comment #23
> Rick, that's plausible. There are enough goofy things going on that event
> queues
> might be involved. Maybe I'll try running the url *after* the property dialog
> is
> dismissed and see if that works, if so, it would point at the modal dialog and
> not the way I'm running the url.

Kasumi in comment #24
> can't reproduce on 2002-06-14-08-1.0.0
> Windows XP pro. JA & Mac OS 9.1 JA
QA Contact: ji → i18n
we don't support the privileges button anymore - marking invalid
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Privileges button still exists.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Really? What server are you using so that you see the privileges button? In any case, I won't be working on this anytime soon.
Assignee: bienvenu → nobody
I believe it's an iPlanet Messaging Server. 
Not that i can actually do anything after clicking it, the link isn't accessible.
my inclination would be to just remove the button - if someone has a use for it, they can write an extension.
Well it's a fairly good way to set privileges (if the server side would be properly configured). 

On the other hand, i'm not sure this bug is actually valid. The quote in comment 4 talks about and what an "URL display program" should use. The question here is wheter the folder name sent in the url should be urlencoded or if modified utf-7 is ok.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.