[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