Groovy strings with < and > characters


(The fish is still dead.) #1

I’m running into an issue with strings. I’m trying to create a string to use as the CALLBACK parameter for a UPnP request, but whenever I try to insert a < or a >, the string goes AWOL.

For example:

String x
x = "http://${hubAddress}/"
log.debug("x: ${x}")

gives the following output:

1:28:47 PM: debug x: http://10.13.13.227:39500/

If I do this:

String x
x = "<http://${hubAddress}/>"
log.debug("x: ${x}")

I get this:

1:28:47 PM: debug x:

I’ve tried escaping the < and > with backslashes, I’ve tried doubling them up, I’ve tried single quotes. What the heck am I missing?


(Kristopher Kubicki) #2

Try to encode the characters with %


(The fish is still dead.) #3

Thanks, but I tried that since I posted the thread. They just show up as %0C (or whatever the actual code was when I looked it up).

I’ve gotten around this a different way, but I’m still interested in the answer if only for the academic aspect.


(The fish is still dead.) #5

Ok, so I THOUGHT I had gotten around this with the following code:

def result = new physicalgraph.device.HubAction(
    method: "SUBSCRIBE",
    path: "/upnp/event/basicevent1",
    headers: [
        HOST: hostAddress,
        CALLBACK: "<http://${hubAddress}/notify>",
        NT: "upnp:event",
        TIMEOUT: "Second-3600"
    ]
)
log.debug(result)

This worked. I saw it. I got a valid subscription. I haven’t touched it.

Now suddenly the value for the CALLBACK parameter has gone missing. Could this be related to the IDE issues this afternoon?

This is what I’m seeing from that last log.debug:

5:46:12 PM: debug SUBSCRIBE /upnp/event/basicevent1 HTTP/1.1 
Accept: */* 
User-Agent: Linux UPnP/1.0 SmartThings 
HOST: 10.13.13.45:49153 
CALLBACK: 
NT: upnp:event 
TIMEOUT: Second-3600 

(The fish is still dead.) #6

Support suggested I tag @mager and @matthewnohr in this thread. I feel like I’m missing something so obviously simple, but nothing I try lets me get a string of the format “http://10.10.10.10/notify”.


(Joshua Lyon (SharpTools.io Dashboard)) #7

I may be missing something about this use-case, but why do you need the <> characters? I would suspect that <something> might be interpreted as an HTML tag and actually get stripped out by the log/browser depending on how it is rendered in the logs.


(The fish is still dead.) #8

It’s for a UPnP request. The <> are required around the CALLBACK value by the spec, unfortunately.


#9

Does this help?

http://groovy.codehaus.org/Strings+and+GString


(Geko) #10

Are you sure it’s not the log who’s messing with your data? I mean what you see in the logs is not necessarily the same what goes down the wire. Have you tried wireshark?


(The fish is still dead.) #11

That’s my next step, geko. Just as soon as I figure out how to get a span port off of my switch. =)

But I KNOW I’ve seen it in the logs correctly before and that when that happened, the subscription was successful.


#12

Ampersand “lt;” and ampersand “gt;” is what you used?

If you used the regular ASCII values of &#60 and 62, it won’t escape brackets in Java because the brackets are reserved control characters, so I’m assuming the same is true for Groovy.


(Geko) #13

I’m pretty sure it’s a logger bug.

Here’s the code:

log.debug "This is a <foobar> test"
log.debug "This is a \074foobar\076 test"

This prints:

xxxx 3:48:15 PM PST: debug This is a test
xxxx 3:48:15 PM PST: debug This is a test

Here’s some more tests:

log.debug 'Test 1: <>'
log.debug 'Test 2: < foobar >'
log.debug 'Test 3: <foobar>'

This prints:

xxxx 4:02:41 PM PST: debug Test 1: <>
xxxx 4:02:41 PM PST: debug Test 2: < foobar >
xxxx 4:02:41 PM PST: debug Test 3:

So it’s not the brackets per se, it’s filtering a token enclosed in brackets (without spaces).

Maybe their intension was to remove hypertext tags from the logs, who knows?


#14

Which version of groovy does ST use? If you want to replace all instances of all 5 reserved characters at once, this looks nice:


(The fish is still dead.) #15

As suspected, the log viewer in the IDE was what was screwing things up. The packets on the wire were, in fact, correct. I’ll update my ticket with support so that they know it’s a bug report.

Thanks, @geko (and everyone else, of course!)