Date: Tue, 26 Oct 2010 09:19:50 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp get failure Message-ID: <1288081190.705299.12876.nullmailer@galant.ukfsn.org> In-Reply-To: <AANLkTinADNrrNLcv964SSds_Ftt-a0uJ5S_3_mBtrbVL@mail.gmail.com> References: <1287509041.022618.4884.nullmailer@galant.ukfsn.org> <AANLkTimVZRNp8oh9%2BVQ6rPbXXFjdNqpgSQ2AqWjqATJY@mail.gmail.com> <1287561876.893861.6837.nullmailer@galant.ukfsn.org> <AANLkTi=V8pm51C4D58KRsiz0FfhOiU=NnUYGQJdeUwxA@mail.gmail.com> <1287732977.227959.8695.nullmailer@galant.ukfsn.org> <1287738768.915002.8520.nullmailer@galant.ukfsn.org> <AANLkTi=iHT9WOVuNq_VFfWo6R3J1ynkhGBV0s6VkS_Uw@mail.gmail.com> <1287857292.298365.1038.nullmailer@galant.ukfsn.org> <AANLkTinU1YpT=kVNHH28fkG2UuMdaRKNWzSmTa4Nq77K@mail.gmail.com> <1287874077.365931.1417.nullmailer@galant.ukfsn.org> <1287909035.704733.393.nullmailer@galant.ukfsn.org> <AANLkTimUBf8ALdpe2JHsS%2BQji-Pf_Ym1BuefCsOVLnHr@mail.gmail.com> <1288042690.562160.2361.nullmailer@galant.ukfsn.org> <AANLkTik%2BBvzyHp_u9iwdT8wG9AMG4eysnFoDvkY5amj4@mail.gmail.com> <AANLkTinADNrrNLcv964SSds_Ftt-a0uJ5S_3_mBtrbVL@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Oct 2010, Maksim Yevmenkin wrote: > i'm convinced that there is a bug in obexapp (or, less likely, > openobex library). it appears that "connection id" header is intended > for multiplexing of several data streams. its pretty much analog of > http "host" header. for what its worth, obexftp-0.20 exhibits the exact same behaviour as obexapp. (there are later versions but I can't be bothered to try and build them at this time, I have submitted patches to clean up Bluetooth support on *BSD over a year ago but the git repository shows no related activity) > i think its clear what "connection id" header must be present on all > requests from the client, including continue-GET request. what is not > entirely clear if the server responses should also contain "connection > id" header. i think they should as well. clearly, wm6 server is not > sending "connection id" header back in its responses, so perhaps its a > double whammy. Hm, are you saying that if the server included the Connection ID in its GET-response, would that make it to the continue-GET (because of OBEX_ObjectReParseHeaders() call)? iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1288081190.705299.12876.nullmailer>