[rt-users] REST interface attachment weirdness
Tom Lahti
toml at bitstatement.net
Tue Feb 24 21:58:36 EST 2009
In the REST interface, if you make a request like:
Request: /REST/1.0/ticket/<ticket-id>/attachments/<attachment-id>
You get a response like:
RT/3.8.2 200 Ok
id: 866
Subject:
Creator: 66
Created: 2008-08-05 00:27:27
Transaction: 2467
Parent: 864
MessageId:
Filename: word.doc
ContentType: application/msword
ContentEncoding: none
o
Headers: Content-Type: application/msword; name="word.doc"
Content-Disposition: inline; filename="word.doc"
Content-Transfer-Encoding: base64
Content-Length: 27648
Content: .....
.....
.....
Now, the content-length says 27648, but the length of everything after
"Content: " is 38884. Noting that it has spaces in it after each newline, I
can search & replace "\n\s{9}" with "\n" and get to 38470 -- I'm still way
above 27648. Now, supposedly this is base64 encoded, according to the
Content-Transfer-Encoding, but if I base64 decode this string of 38470 I get
a string that is 2314 bytes.
Worse, the actual file size is 31332, which is what I get when I download it
through the web interface interactively. This is greater than the
Content-Length header, and less than the "content" returned. This is
obviously a bit puzzling.
If I use the REST request
/REST/1.0/ticket/<ticket-id>/attachments/<attachment-id>/content
I get the correct content, plus 3 extra carriage returns. But I don't get
the filename, the size, or the content type. I could do both, but then I'm
downloading the content from the REST interface twice per attachment, which
is silly, especially if its necessary to scale.
Is there a way I can reconstruct the content correctly from the former REST
call, or get the filename/content type/encoding with the latter? I'd hate
to have to rely on patching the REST interface and then maintaining the
patch for when we upgrade.
--
-- ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
-- ============================
More information about the rt-users
mailing list