One quirky behavior of Lync users is that they will sometimes send other users hyperlinks and it seems rather straightforward in how handling should happen, but I wouldn’t be writing about it if that was the case. The first time I sent a hyperlink (http://ucwa.lync.com) from Lync Client I noticed that the result was a bit different than what appeared in the conversation window: http://ucwa.lync.com <http://ucwa.lync.com>. With a bit of substitution it was possible to see that the result: http://ucwa.lync.com <http://ucwa.lync.com>. While it is possible to do some transformations to remove the repeated value and turn the first into a usable hyperlink it will be easier to act the problem at the source and by that I’m referring to MessageFormat.
Enabling Html Formatted Messages
Inspecting the Communication resource it is possible to see a supportedMessageFormats property and by default UCWA has this collection set to Plain.
Executing a PUT request on the Communication resource would allow Html formatted messages to come across containing Html tags and CSS styles relating to the content the user sent, meaning the original hyperlink should come across as an anchor tag. My first few attempts at structuring a PUT resulted in 400 (Bad Request). I felt I had everything in place with the addition of Html under supportedMessageFormats and could not determine why it would not accept the request.
Since Communication provides an ETag value we should provide the If-Match header with the supplied ETag value. In the event that the If-Match value does not match the ETag it will respond with a 412 (Precondition Failed). Assuming the PUT request succeeds with a 204 response it is now possible to see Html formatted messages. In the original example the message would come across as: <span style=”margin-bottom:0pt;font-size:10pt;line-height:normal;”><a href=”http://ucwa.lync.com/” title=”http://ucwa.lync.com/”><span style=”color:black;”>http://ucwa.lync.com</span></a></span>. It would be possible to put this into a message container and have a functional hyperlink (hopefully).
Fiddler Traces: UCWA Html Messaging and LWA Html Messaging
Side Effects
One side effect of enabling Html formatted messaging is that all messages will come across as Html formatted. I looked into LWA (Lync Web App) and found the behavior to be that both Plain and Html formatted messages were returned for each message. I played around with changing Content-Type headers, but have not come to a conclusion why UCWA is only returning Html formatted messages when both MessageFormats are enabled.
Fiddler MimeParser Updates
I had not intended on doing too much additional work on the original Mime-Parser I wrote about back in August (UCWA & Deciphering multipart/batching with Fiddler), but while doing some debugging I noticed it had a few issues:
- Navigating between request/response items that were not multipart/batch after previously displaying could lead the misconception that the current response was being processed.
- Transfer-Encoding: Chunked messages would attempt processing and fail because the body would not decode.
- No support for multipart/related or multipart/alternative.
I figured based on the changes I had working locally there was no reason not to clean it up a bit and put out a newer version. If nothing else to have a publicly accessible location point people I work with at when they ask me about how I read some of the more complex UCWA traffic.
Latest MimeParser: MimeParser 1.0.1.7z
Next Up
I may have some material ready on simplifying configuration of UCWA and the cross-domain authorization otherwise I’ll find more information and a possible solution to getting Plain and Html formatted messages when using UCWA.