Mantis Bugtracker
главная | моя сводка | список вопросов | журнал изменений | план развития | документация | моя учетная запись
  

Простой вид [ комментарии ] [ расширенный вид ] [ история ] [ печать ]
Номер Категория Серьезность Воспроизводимость Создан Изменен
0000242 [obex-data-server] General большая всегда 2009-12-09 15:53 2010-11-01 19:39
Инициатор cgarcia Видимость общая  
Ответственный
Приоритет обычный Решение открыт  
Состояние новый   Версия продукта 0.4.5
Суть 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.
Дополнительные сведения
Tэги Нет прикрепленных тэгов.
Вложенные файлы

- Связи

-  Комментарии
(0000868)
skirsdeda (администратор)
2009-12-11 16:11

 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.
(0001396)
nami (инициатор)
2010-10-28 06:21

 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:

if(!final)
    is_delete = FALSE;

But this modification need ods_obex_srv_put add one function parameters: gboolean final.
(0001397)
skirsdeda (администратор)
2010-10-28 13:41

 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;
(0001402)
nami (инициатор)
2010-10-29 08:19

 You can see in obex_server function,the self->obejcet->cmd is saved with final bit filtered out:

 cmd = request->opcode & ~OBEX_FINAL;

 case STATE_IDLE:
             .
             .
             .
      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?
(0001405)
skirsdeda (администратор)
2010-11-01 19:39

 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 Новый вопрос
2009-12-11 16:11 skirsdeda Комментарий добавлен: 0000868
2010-10-28 06:21 nami Комментарий добавлен: 0001396
2010-10-28 13:41 skirsdeda Комментарий добавлен: 0001397
2010-10-29 08:19 nami Комментарий добавлен: 0001402
2010-11-01 19:39 skirsdeda Комментарий добавлен: 0001405

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker