This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

< and > being recognized as MXP

Posted by Ircria on Fri 19 Aug 2011 06:20 AM — 4 posts, 18,803 views.

Ircria #0
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 &lt; and &gt; 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 &lt;#&gt; &lt;   54 20 26 6c 74 3b 23 26 67 74 3b 20 26 6c 74 3b
property&gt; &lt   70 72 6f 70 65 72 74 79 26 67 74 3b 20 26 6c 74
;value&gt;  -  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 &lt; and &gt; 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.
Amended on Fri 19 Aug 2011 10:13 AM by Nick Gammon
Nick Gammon Australia Forum Administrator #1
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 &lt; and &gt; being handled incorrectly.

The mode changes are actually in the packet:


z..[0z      ZEDI


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 Australia Forum Administrator #2
Ircria said:

EDIT2: The &lt; and &gt; 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 &lt; and &gt; to display correctly, but not <send> and stuff like that.
Ircria #3
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.