| Summary: | jingle-share protocol silently drops most file transfer properties & metadata | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Will Thompson <will> |
| Component: | gabble | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | matus |
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | libreoffice-tubes | ||
| i915 platform: | i915 features: | ||
(In reply to comment #0) > (using a confusing bit > of logic in gabble_file_transfer_channel_offer_file() which I am about to > clarify). Confusing enough that I misunderstood it while trying to simplify it. Hooray for tests. I'll just leave it. So, more specifically. offer_bytestream() in ft-channel.c adds desc="" attributes etc. and also calls add_metadata_forms(): http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/ft-channel.c#n1195 But when using the GTalk file transfer protocol, offer_gtalk_file_transfer() is called instead <http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/ft-channel.c#n1339> which ultimately calls produce_description() <http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/jingle-share.c#n443> which as you can see does not add a description or anything. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/220. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
When offering a file transfer, if the peer has the jingle-share cap and we have a Google relay token, Gabble prefers to use jingle-share (using a confusing bit of logic in gabble_file_transfer_channel_offer_file() which I am about to clarify). Unfortunately, the offer includes almost none of the Channel.Type.FileTransfer or Channel.I.FileTransfer.Metadata properties: * iq xmlns='jabber:client' type='set' to='yyy' id='77863471642' * session xmlns='http://www.google.com/session' initiator='xxx' id='568990973' type='initiate' * description xmlns='http://www.google.com/session/share' * manifest * file size='5343' * name "write-manager-file.py" * protocol * http * url name='source-path' "/temporary/fefff52b-3e03-40a1-8370-6bed61a4935b/" * url name='preview-path' "/temporary/68a248ad-1173-4abc-80ae-66e0614aadc1/" * transport xmlns='http://www.google.com/transport/p2p' This broke my attempt to use Metadata.ServiceName to make LibreOffice a BypassApprovers-flavoured handler for file transfers directed to it. It also broke my follow-up attempt to (ab)use Description for the same purpose. Whether or not adding extra data (like ContentType, etc.) to the <file/> element would break Google clients, it seems reasonable (at the very least) to include everything if we know the peer supports our Metadata extension.