Edgewall Software
Modify

Opened 11 years ago

Last modified 11 years ago

#10021 new defect

Rendering of URI samples

Reported by: mpotter@… Owned by:
Priority: low Milestone: unscheduled
Component: wiki system Version: 0.12-stable
Severity: minor Keywords:
Cc: mpotter@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

While trying to document a sample SIP URI I found I could not simply italic the variable part of the URI. On further experimentation I found this seams to affect any scheme:hier-part URIs. The obvious escaping of the scheme tag did no resolve the issue.

Examples:

 * sip:N''access-code''@192.168.0.20
 * !sip:N''access-code''@192.168.0.20
 * mailto:Subscribe-''conference''@192.168.0.10
 * !mailto:Subscribe-''conference''@192.168.0.10
 * ftp://ftp.domain.com/''path''/''file''
 * !ftp://ftp.domain.com/''path''/''file''

Gives:

  • sip:N''access-code''@192.168.0.20
  • sip:N''access-code''@192.168.0.20
  • mailto:Subscribe-''conference''@…
  • mailto:Subscribe-''conference''@192.168.0.10
  • ftp://ftp.domain.com/''path''/''file
  • ftp://ftp.domain.com/''path''/''file

Work-around: Use the monospace markup to avoid the processing of the scheme, example:

 * `sip:N`''access-code''`@192.168.0.20`
 * `mailto:Subscribe-`''conference''`@192.168.0.10`
 * `ftp://ftp.domain.com/`''path''`/`''file''

Gives:

  • sip:Naccess-code@192.168.0.20
  • mailto:Subscribe-conference@192.168.0.10
  • ftp://ftp.domain.com/path/file

Attachments (0)

Change History (4)

comment:1 by Christian Boos, 11 years ago

Yes, this happens because we first match sip:N''access-code''@192.168.0.20 as a link, then we reject it as sip is not a known protocol. Same happens when the link is "escaped" with !, it's first recognized as a whole. You can see that effect on the ftp: and mailto: links.

Having a kind of recursive parsing for the rejected text and trying other patterns but the one that failed seem difficult to implement efficiently. So workarounds like the one you found seems to be the only realistic approach for now.

But I'm interested to hear suggestions.

comment:2 by Christian Boos, 11 years ago

Component: renderingwiki system
Milestone: unscheduled

comment:3 by Mark Potter <mpotter@…>, 11 years ago

A similar problem comes up in the standard C parser. Take for example the line:

x = (foo)-(bar);

The basic lexical analyzer sees this as:

IDENTIFIER '=' '(' IDENTIFIER ')' '-' '(' IDENTIFIER ')' ';'

However that could be parsed two different ways, either

variable assignment_operator variable minus variable

or

variable assignment_operator type_cast negative variable

The way this is typically resolved is the parser maintains a type-definition table and then the lexical analyzer checks this table for each possible IDENTIFIER returning either IDENTIFIER or TYPE_NAME to the parser.

With that in mind I would think that this could be better handled if the parser could recognize the valid URL prefixes up front. Alas this would only work for the sip: case, since Trac currently does not support this prefix, but would not for the mailto: or ftp: cases.

The only other solutions I can think of are:

  • Add some sort of new scope limiting syntax.
    {sip:N}''access-code''@192.168.0.20
    {mailto:}Subscribe-''conference''@192.168.0.10
    {ftp:}//ftp.domain.com/''path''/''file''
    
  • Utilize the already existing square-bracket as a scope limiter. Basically making [! a special case.
    [!sip:N]''access-code''@192.168.0.20
    [!mailto:]Subscribe-''conference''@192.168.0.10
    [!ftp:]//ftp.domain.com/''path''/''file''
    

in reply to:  3 comment:4 by Mark Potter <mpotter@…>, 11 years ago

Replying to Mark Potter <mpotter@…>:

  • Utilize the already existing square-bracket as a scope limiter. Basically making [! a special case.

I was thinking that '[' and ']' were not valid characters in a URL. However looking at the grammar in RFC3986 it appears that they can in the host as a way to specify an IPv6 address.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.