issue for header parser with HTTP _client lib

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
MaCa_2922036
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

Hello,

I am using the hardware module 1LD 43438 with Wiced v6.4.

I meet a new issue with the http_client lib (the 1st one on this ticket, currently still have no answer). The lib can be found here : ".../libraries/protocols/HTTP_clent/http_client.c". I also put the files enclosed.

The communication is done with HTTP request to a server on which I am downloading a .elf file for an OTA update. This file is downloaded by chunk of 1024 bytes.

HTTP request sent to the server:

 

GET https://[**hidden**].s3.eu-west-3.amazonaws.com/MyFile.stripped.elf
Host: [**hidden**].s3.eu-west-3.amazonaws.com
Range: bytes=362496-363519

 

HTTP response received from the server:

 

HTTP/1.1 206 

Date: Fri, 30 Jul 2021 12:57:16 GMT

Content-Type: binary/octet-stream

Content-Length: 1024

Connection: keep-alive

Content-Range: bytes 362496-363519/441816

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0



Sec-WebSocket-Version: 13HTTP/1.1 101 Switching Protocols

HTTP/1.1 404 Not Found258EAFA5-E914-47DA-95CA-C5AB0DC85B11HTTP/1.0Unable to handle fragmented packetsHTTP/* * *

*Content-LengthTransfer-Encoding: chunkedWrong MAX_FRAGMENT_LENGTH value Unable to set TLS extensionƒH‹HH”H™HH¤HªHHTTP/2OPTIONSGETHEADPOSTPUTDELETETRACECONNECTmalloc_mutexsystem monitorCouldn't create system monitor thread; err = %d
app threadEvent flagsworker queueworker threadStarted ThreadX v5.8Failed to create WICED_HARDWARE_IO_WORKER_THREADFailed to create WICED_NETWORKING_WORKER_THREADbsscfg:event_msgsbsscfg:event_msgs_ext0@ Could not initialize wifi platform****************************************************
** ERROR: WLAN: could not download clm_blob file
** FATAL ERROR: system unusable, CLM blob file not found or corrupted.
****************************************************bus:txglomCould not turn o

 

If you have a look on the lib http_client.c,  the function "deferred_receive_handler" is responsible to provide the http response from the lib to the application. at the line 511, the function try to detect if the header contains the key-word "Transfer-Encoding: chunked". If founded, the response is not managed as this case is not implemented in the lib. It should not be an issue as the server does not answer me with this kind of encoding.

However, the lib seems to looking for this keyword in the entire http response "fragment_available_data_length" (which is the header + the payload) instead of looking for only in the payload.

In my case, the file which I am trying to download, contains the string sequence in ascii format "Transfer-Encoding: chunked". Even if this string is contained in the payload, and not in the header, the lib detect it and the App is not able to process the payload as it is blocked by the lib (enter in the line 513 with the //TODO comment).

=> Could you explain why the lib is looking for the keyword in the entire header+payload data instead of in the header only ? Or is it a bug ?

=> how to handle this issue ?

I think you can easily reproduce this issue with any platform, using the exemple from Cypress Academy WW101 : CypressAcademy_WW101_Files-master\Projects\ww101key\07c\09_aws_get.

If needed for your test, I can share the link to download the .elf file in private message.

 

0 Likes
16 Replies
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

Hello @MaCa_2922036 

The link to the previous thread seems to be broken. 

Can I reproduce the issue with the default 09_aws_get example or do I need to use the code that you attached? 

0 Likes
MaCa_2922036
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

Hello.

I updated the link, it should work now.
The files enclosed or directly comes from the default install of wiced v6.4 without any change. You can use both as files should be identicals.

0 Likes

Since this is a replicate of the issue reported in the link mentioned. We will try to resolve the query in the original thread.

0 Likes

No idea why you said this is a replicated issue.
If you do read the original issue report, you should know this one is totally different from the linked issue.

0 Likes

I agree with .

The issue seems to comes from the same lib file, but with a different root cause. So please, do not wait for the answer of the other topic to start investigate this one.

Does anybody even try to reproduce this issue ? Could be a good beginning for investigation ...

Thanks.

0 Likes
MaCa_2922036
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

Hello,

Does anybody reproduced the issue ?

Does anybody investigates ?

0 Likes

Hello @MaCa_2922036 

Apologies for the delay and the inconvenience. I haven't been able to reproduce this and investigate this yet. Will try to provide an update by this week.

Thanks

0 Likes
SChaudeurge
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

Hello @Murali_R ,

Why are you not able to reproduce the issue ? do you miss any information ? did you ask for missing information ?

The ticket is opened for 2 months now and we waited such a long time just to learn that you say you are not able to reproduce it without any more details !  and you said you will TRY to have a look on this point this week !

Please engage more task force to provide an acceptable technical response on this issue. It is a critical and blocking point for our projet.

0 Likes
SChaudeurge
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

As nobody from Wiced support seems concerned by this issue, I did the work and analyze the http_client librairie.

Could you have a look on the file \librairies\protocols\HTTP_client\http_client.c, at the line 511:

 

 

if ( strnstrn( (char*)data, fragment_available_data_length, HTTP_HEADER_CHUNKED, sizeof( HTTP_HEADER_CHUNKED ) - 1 ) )

 

 

==> can you just explain me why the lib is looking for the "HTTP_HEADER_CHUNKED" keyword in the entire data received which is the header+payload (pointer from @"data" with a length of "fragment_available_data_length");

instead of just looking for this keyword in the header only ((pointer from @"data" with a length of  " response_hdr_length":

in other word, replace the current l.511 by this:

 

 

if ( strnstrn( (char*)data, http_response.response_hdr_length, HTTP_HEADER_CHUNKED, sizeof( HTTP_HEADER_CHUNKED ) - 1 ) )

 

 

 

0 Likes
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

If you change the fragment_available_data_length to http_response.response_hdr_length, does the issue get fixed? If so please go ahead and use it.

This might be a possible bug that exists in the library which we might have missed in our tests since there is no routine implemented there.

0 Likes

@Murali_R wrote:

If you change the fragment_available_data_length to http_response.response_hdr_length, does the issue get fixed? If so please go ahead and use it.

This might be a possible bug that exists in the library which we might have missed in our tests since there is no routine implemented there.


Can your team confirm if this fix is correct or not?
If the fix is correct, please make sure new sdk version include the fix.

0 Likes

Yes, the fix is fine and we don't see any issues as such.

0 Likes

@Murali_R wrote:

Yes, the fix is fine and we don't see any issues as such.


Then please make sure next release includes the fix.
I have complaint several times that new release does not include the fixes for the issues reported and resolved on the forum.
What make thing even worsen is the administrator lock the topics so I even cannot remind you guys which fix was lost in latest release.

Thank you @Murali_R for this confirmation.

I am also agree with @AxLi_1746341 about the implementation in the next release. And generally, I am very disappointed by the Wiced libs which are buggy or incomplete (lots of "todo" and "fixme" task remains on the official released version). This is not acceptable for industrial product. In addition the technical support is a not enough responsive, and many opened ticket on the community still remains without clear answer after months.

I hope you will make effort on those points.

0 Likes
SChaudeurge
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

This patch on the lib seems to correct this issue. So, yes, I can go ahead with this modification. However I need the expert point of view of the software teams to confirm:

- if this behaviour is wanted or if it is a bug

- if the proposed patch may have any side effect or if it safe.

Thanks.

0 Likes
serpodrik
Level 1
Level 1
First reply posted Welcome!

Hello ,

Why are you not able to reproduce the issue ? do you miss any information ? did you ask for missing information ?

The ticket is opened for 2 months now and we waited such a long time just to learn that you say you are not able to reproduce it without any more details !  and you said you will TRY to have a look on this point this week Pourquoi Omegle est meilleur  !

Please engage more task force to provide an acceptable technical response on this issue. It is a critical and blocking point for our projet.

0 Likes