I’ve filed a bug report. Login
This is probably the 3rd time its come up. I’ve discussed it with Jesse on the RT user’s list and he recommended filing a bug report the last time it came up. The problem isn’t really with rt-client, its with RT. This non-compliance with RFC 822 when that was intended will cause not only rt-client to fail, but other similar libraries as well that use a 3rd party RFC 822 parser. Having a space in the field name of an RFC 822 header is not compliant with the RFC.
I suspect that Jesse or someone at Best Practical will patch up RT in a future release to close this hole in their RFC compliance by doing a placeholder substitution, possibly with the addition of a config variable to turn the substition on/off so that those who aren’t broken and depend on the space don’t get broken by the fix. Or, they might do it by simply not claiming RFC 822 compliance on the REST interface 
Tom Lahti, SCMDBA, LPIC-1, CLA
BIT LLC
425-251-0833 x 117On Jan 10, 2011, at 1:10 AM, Brian McArdle wrote:
Hi Tom,
First and foremost, thanks a million for the gem, makes my life a lot
easier!
We did hit one issue though - we have some custom fields which contain
spaces, and this causes TMail to crash with a SyntaxError:
TMail::SyntaxError (wrong mail header: ‘“CF.{Impacts SLA}: NO\n”’):
app/controllers/portal_controller.rb:34:in `tickets’
I managed to remedy this with the below code, which you might be
interested in putting in the source. I inserted it everywhere in
client.rb where you made adjustments for Tmail (e.g. line 153).
[snip]
smime.p7s (2.87 KB)
I’ve filed a bug report. Login
This is probably the 3rd time its come up. I’ve discussed it with Jesse on the RT user’s list and he recommended filing a bug report the last time it came up. The problem isn’t really with rt-client, its with RT. This non-compliance with RFC 822 when that was intended will cause not only rt-client to fail, but other similar libraries as well that use a 3rd party RFC 822 parser. Having a space in the field name of an RFC 822 header is not compliant with the RFC.
I don’t think we’ve ever claimed to be RFC 822 compliant. Have we?
It was in something I read somewhere regarding the REST interface. Maybe it was in the wiki and someone else wrote it.
Tom Lahti, SCMDBA, LPIC-1, CLA
BIT LLC
425-251-0833 x 117
smime.p7s (2.87 KB)
Surely you remember this thread as well?
http://www.mail-archive.com/rt-users@lists.bestpractical.com/msg28493.html
Tom Lahti, SCMDBA, LPIC-1, CLA
BIT LLC
425-251-0833 x 117On Jan 10, 2011, at 4:27 PM, Tom Lahti wrote:
It was in something I read somewhere regarding the REST interface. Maybe it was in the wiki and someone else wrote it.
–
Tom Lahti, SCMDBA, LPIC-1, CLA
BIT LLC
425-251-0833 x 117
I’ve filed a bug report. Login
This is probably the 3rd time its come up. I’ve discussed it with Jesse on the RT user’s list and he recommended filing a bug report the last time it came up. The problem isn’t really with rt-client, its with RT. This non-compliance with RFC 822 when that was intended will cause not only rt-client to fail, but other similar libraries as well that use a 3rd party RFC 822 parser. Having a space in the field name of an RFC 822 header is not compliant with the RFC.
I don’t think we’ve ever claimed to be RFC 822 compliant. Have we?
smime.p7s (2.87 KB)
Ah, I know where I got the idea. RT::Client::REST on CPAN uses Mail::RFC822::Address from CPAN, I believe.
The evilness of spaces in field-names is far less than the one back in October, with null lines preceeding and after a header in the metadata, which is how the body is supposed to be separated from the metadata. Not sure how that one happens, but it makes parsing rather difficult.
Tom Lahti, SCMDBA, LPIC-1, CLA
BIT LLC
425-251-0833 x 117On Jan 10, 2011, at 4:34 PM, Tom Lahti wrote:
Surely you remember this thread as well?
Re: [rt-users] REST interface and long file names?
smime.p7s (2.87 KB)