Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hi

We are having the following problem with Samsung A530/A610 devices:

We send a HTTP request using IWEB_GetResponse like this:

IWEB_GetResponse(pCore->m_CommInfo.m_pWeb,
(pCore->m_CommInfo.m_pWeb, &pState->m_pWebResp,
&pState->m_callback, pState->m_pszUrl,
WEBOPT_HANDLERDATA, &pCore->m_CommInfo,
WEBOPT_HEADER, pState->m_pszHeader,
WEBOPT_CONNECTTIMEOUT,5000,
WEBOPT_METHOD, "POST", WEBOPT_USERAGENT, CLIENT_NAME,
WEBOPT_BODY, pState->m_pPostData,
WEBOPT_CONTENTLENGTH, pCore->EncodingInstance.pBuffer->pCurrentPos - pCore->EncodingInstance.pBuffer->pBuffer,
WEBOPT_END));

And sometimes (yet not clear enough at what conditions) the Content-Length the server get from this packet is corrupted. It's not even a number, it's just several unprintable symbols, for example, string that consists of characters with codes 10h e6h 08h 01h.
The same code works fine in same conditions (same data sent) on other handsets, like all LG handsets and Kyocera.

I'll continue a search for the problem myself, but I just wonder if there is, probably, known issue with Samsung handsets and IWEB interface? Or, probably, there are requests for support from other developers with the same or similar problems?

We are using Samsung A610, S/W ver. A610.WL30 at Verizon Wireless network. May this somehow be an operator issue?

Anyway, another question is just HOW is this possible to convert a number into unprintable characters? This really looks to me like a handset/BREW bug, or some network gateway problem. Maybe you can make some reasonable assumptions on how could such a thing happen?

Check this thread, might be the cause of your problems:
http://brewforums.qualcomm.com/showthread.php?t=1398

Check this thread, might be the cause of your problems:
http://brewforums.qualcomm.com/showthread.php?t=1398

Thanks, that's interesting. I don't think that's the particular case, but, probably, those problems are closely related.
You said "known issue with some handsets". Could you, please, name those handsets? And some details on the issue?
As I understood from the workaround code, for those handsets the request should have a length more than some particular number? What is this number?
I personally don't like an idea of adding overhead to a traffic, probably the better way is to know the particular handset, the "magic number" and add exactly as much foo-headers as required by handset. So, I'd really like to get those details :)

Thanks, that's interesting. I don't think that's the particular case, but, probably, those problems are closely related.
You said "known issue with some handsets". Could you, please, name those handsets? And some details on the issue?
As I understood from the workaround code, for those handsets the request should have a length more than some particular number? What is this number?
I personally don't like an idea of adding overhead to a traffic, probably the better way is to know the particular handset, the "magic number" and add exactly as much foo-headers as required by handset. So, I'd really like to get those details :)