Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ < and > being recognized as MXP
|
< and > being recognized as MXP
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Ircria
(24 posts) Bio
|
| Date
| Fri 19 Aug 2011 06:20 AM (UTC) Amended on Fri 19 Aug 2011 10:13 AM (UTC) by Nick Gammon
|
| Message
| I've recently encountered some issues with MXP tags not being registered normally after certain strings of text are received. Opening the MXP debugger and packet debug in MUSHclient, I have found the following is happening:
I 10008: ( 2637) MXP mode change from 'permanently secure' to 'open'
A 20001: ( 2637) MXP entity: <
A 20001: ( 2637) MXP entity: >
I 10008: ( 2637) MXP mode change from 'open' to 'permanently secure'
I 10008: ( 2638) MXP mode change from 'permanently secure' to 'open'
A 20001: ( 2638) MXP entity: <
A 20001: ( 2638) MXP entity: >
I 10008: ( 2638) MXP mode change from 'open' to 'permanently secure'
I 10008: ( 2639) MXP mode change from 'permanently secure' to 'open'
A 20001: ( 2639) MXP entity: <
A 20001: ( 2639) MXP entity: >
A 20001: ( 2639) MXP entity: <
A 20001: ( 2639) MXP entity: >
A 20001: ( 2639) MXP entity: <
A 20001: ( 2639) MXP entity: >
I 10008: ( 2639) MXP mode change from 'open' to 'permanently secure'
I 10008: ( 2640) MXP mode change from 'permanently secure' to 'open'
A 20001: ( 2640) MXP entity: <
A 20001: ( 2640) MXP entity: >
I 10008: ( 2640) MXP mode change from 'open' to 'permanently secure'
I 10008: ( 2641) MXP mode change from 'permanently secure' to 'open'
I 10008: ( 2641) MXP mode change from 'open' to 'permanently secure'
I 10008: ( 2645) MXP mode change from 'permanently secure' to 'open'
A 20001: ( 2645) MXP entity: <
A 20001: ( 2645) MXP entity: >
A 20001: ( 2646) MXP entity: <
A 20001: ( 2646) MXP entity: >
A 20001: ( 2647) MXP entity: <
A 20001: ( 2647) MXP entity: >
on the text:
UNZONE <start #> [end #] - Remove zone setting from room(s).
WRITEHELP <name/#> - Bring a helpfile into your editor.
ZEDIT <#> <property> <value> - Edit the details of a zone.
ZMOTE [#] <text> - Show your current zone a message.
ZSWEEP - Sets zone on all rooms.
Added Privileges
------------
CALLFUNC <function> - Give no arg for list of functions.
NUKEMOB <start #> [end #] - Destroy one or more mobiles.
ANNOUNCE <message> - Make an OOC announcement.
In the packet debug, I found that these strings were using < and > as such:
your editor..[6 20 79 6f 75 72 20 65 64 69 74 6f 72 2e 1b 5b 36
z..[0z ZEDI 7a 0a 1b 5b 30 7a 20 20 20 20 20 20 5a 45 44 49
T <#> < 54 20 26 6c 74 3b 23 26 67 74 3b 20 26 6c 74 3b
property> < 70 72 6f 70 65 72 74 79 26 67 74 3b 20 26 6c 74
;value> - E 3b 76 61 6c 75 65 26 67 74 3b 20 20 2d 20 20 45
dit the details 64 69 74 20 74 68 65 20 64 65 74 61 69 6c 73 20
These strings are leaving the mode open instead of secure, preventing the following MXP from being displayed properly:
.[0m.[37m.[0m.[1;36m<send href="tell Agesira " PROMPT>Agesira</send>.[0m, .[0m.[1;33m<send href="tell Yuri " PROMPT>Yuri</send>.[0m, .[0m.[1;32m<send href="tell Selkrener " PROMPT>Selkrener</send>.[0m, .[0m.[1;36m<send href="tell Dagon " PROMPT>Dagon</send>.[0m, .[0m.[1;33m<send href="tell Isshel " PROMPT>Isshel</send>.[0m, .[0m.[1;36m<send href="tell Iviyx " PROMPT>Iviyx</send>.[0m and .[0m.[1;32m<send href="tell Cally " PROMPT>Cally</send>.[0m..[0m.[37m.[1;32m1530.[0m.[37m/1530h, .[32m.[1m1080.[0m.[37m/1080m eblrgcxs- [06:38:38:661] ÿù
The following is given in the MXP debug in MUSHclient on that packet:
A 20000: ( 2660) MXP element: <send href="tell Agesira " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
A 20000: ( 2660) MXP element: <send href="tell Yuri " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
A 20000: ( 2660) MXP element: <send href="tell Selkrener " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
A 20000: ( 2660) MXP element: <send href="tell Dagon " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
A 20000: ( 2660) MXP element: <send href="tell Isshel " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
A 20000: ( 2660) MXP element: <send href="tell Iviyx " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
A 20000: ( 2660) MXP element: <send href="tell Cally " PROMPT>
E 1024: ( 2660) Secure MXP tag ignored when not in secure mode: <send>
A 20000: ( 2660) MXP element: </send>
W 5005: ( 2660) Closing MXP tag </send> does not have corresponding opening tag
The string that is being blocked is, as specified in the MXP specification, using < and > (was grabbed with packet debug)
EDIT2: The < and > do display in the output, unlike the normal MXP. This does lead me to believe that they are being treated as both literal and MXP instead of just literal as specified in the MXP spec. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Fri 19 Aug 2011 10:21 AM (UTC) |
| Message
| It's a bit hard to tie up your displays with each other. The packet debug for example doesn't cover everything you showed, and it isn't obvious which lines numbers refer to what.
But what is the bug exactly? I don't see anywhere in what you posted about < and > being handled incorrectly.
The mode changes are actually in the packet:
The sequence ESC [ 0z switches to open mode, which the MXP debug is telling you it is doing. The server must have left it in open mode, so that subsequent stuff like:
<send href="tell Agesira " PROMPT>
is being rejected because it isn't in secure mode.
Sounds like a server bug, unless you can paste some packet debug that clearly shows that the server has switched back to secure mode, and the client has ignored that. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Fri 19 Aug 2011 10:23 AM (UTC) |
| Message
|
Ircria said:
EDIT2: The < and > do display in the output, unlike the normal MXP. This does lead me to believe that they are being treated as both literal and MXP instead of just literal as specified in the MXP spec.
See:
http://www.gammon.com.au/forum/?id=222
From that page:
Quote:
Open mode
This mode is used to allow a "harmless subset" of MXP commands, such as <b> for bold, and <i> for italic.
Open mode is the default mode after a newline is received (unless the <MXP DEFAULT_OPEN> or <MXP DEFAULT_LOCKED> tags have been received, see below).
To switch to open mode the following sequence is sent from the server to the client:
<esc>[0z
which in hex is: 0x1B 0x5B 0x30 0x7A
At present the following tags are allowed in open mode:
<bold> or <b>
<underline> or <u>
<italic> or <i>
<color> or <c>
<font>
<strike> or <s>
<strong>
<small>
<tt>
Note - if a "secure" tag is received on an open line MUSHclient does not display it. However an error message will appear in the error log, if you have the MXP debug level (Configuration -> Output tab) set to anything other than "none".
Thus I expect < and > to display correctly, but not <send> and stuff like that. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Ircria
(24 posts) Bio
|
| Date
| Reply #3 on Fri 19 Aug 2011 10:59 AM (UTC) |
| Message
| | Ah, yes... My mistake. Didn't notice that, and upon checking the code that sends it from the MUD, it sends the ESC[0z code twice instead of 0z then 6z. My apologies for bothering you with this. | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
16,947 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top