|Anonymous | Login | Signup for a new account||2017-05-23 10:03 EEST|
|Main | My View | View Issues | Change Log | Roadmap | Docs | My Account|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000242||[obex-data-server] General||major||always||2009-12-09 15:53||2010-11-01 19:39|
|Summary||0000242: delete not compliant with obex specification|
I have debugged a communication problem (with a own-developed client) until finding that the server does not follows the OBEX specification for deleting files, potentially causing data transmissions to be incorrectly handled as if they were file deletions. Since I have previously used the same client and never found a problem (both with other linux and Windows/Mac obex servers) I suspect that this may cause incompatibilities with many other clients out there, depending on their design.
I detected the problem in the 0.4.4 version ship with ubuntu karmic, but it is still present in the subversion trunk (I have not tested previous versions). The problem is due to the following: the function ods_obex_srv_put() in ods-obex.c considers that the PUT request is a file deletion (is_delete = TRUE) unless the client has previously sent any of the following headers: OBEX_HDR_BODY, OBEX_HDR_TYPE or OBEX_HDR_LENGTH. Since my client do not sends the type nor the length (unknown at transmission start) and it does not sends a body header in the first packet, obex-data-server incorrectly interpretes this as a file deletion and aborts the data transmission.
The OBEX specification (at least 1.2) says about delete:
"A PUT operation with NO Body or End-of-Body headers whatsoever should be treated as a delete request. Similarly, a PUT operation with an empty End-of-Body header requests the recipient to create an empty object. This definition may not make sense or apply to every implementation (in other words devices are not required to support delete operations or empty objects)."
That is, it mentions the complete "PUT operation" (not the first packet) and includes a "whatsoever" word. In another section, the specification is even more clear about this fact:
"A PUT request consists of one or more request packets, the last of which has the Final bit set in the opcode. The implementer may choose whether to include an object Body header in the first packet, or wait until the response to the initial packet is received before sending any object body chunks."
I was one of those implementers choosing not to send a body header in the first packet. My current workarround in order to improve the compatibility with previous obex-data-server versions it will be to include a OBEX_HDR_TYPE.
|Tags||No tags attached.|
|I could try rewriting code so that decision whether file should be deleted would be made at the end of PUT request. This would definitely be a correct way to handle this.|
The FTP specification (D13r10) says that a delete request opcode must be 0x82.So I think ods should check the opcode final bit on its first put request pakage.
If the received package final bit is 0,then this put request(opcode 0x02) certainly shall not be a delete request.If the final bit is 1, then we need to check OBEX_HDR_BODY, OBEX_HDR_TYPE and OBEX_HDR_LENGTH to determin whether this request is a delete request.
Maybe we can add some code in ods_obex_srv_put like this:
is_delete = FALSE;
But this modification need ods_obex_srv_put add one function parameters: gboolean final.
This is a good idea. Although in opcode that we get in event handlers final bit is filtered out, I suppose something like this should be possible in ods_obex_srv_put:
int final = OBEX_ObjectGetCommand(obex_context->obex_handle, object) & OBEX_FINAL;
You can see in obex_server function,the self->obejcet->cmd is saved with final bit filtered out:
cmd = request->opcode & ~OBEX_FINAL;
self->object->cmd = cmd;
You if we call OBEX_ObjectGetCommand function in ods_obex_srv_put,the return command final bit is already filtered out.Maybe we can add a variable in object struct? Like cmd_bak?
|Patching openobex to achieve this is obviously not an option. The only way to fix this is by deleting only in the end of request (at REQ_DONE), since by the end of request we can know for sure if we received any data or if we received BODY header.|
|2009-12-09 15:53||cgarcia||New Issue|
|2009-12-11 16:11||skirsdeda||Note Added: 0000868|
|2010-10-28 06:21||nami||Note Added: 0001396|
|2010-10-28 13:41||skirsdeda||Note Added: 0001397|
|2010-10-29 08:19||nami||Note Added: 0001402|
|2010-11-01 19:39||skirsdeda||Note Added: 0001405|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|