Ethernet IAP doesnt work with newer browsers. How to fix?

[Thomas K]

Hello,

I got the IAP example running and found that it does not work properly with newer browsers (i tried Chrome, Firefox, Edge, all of newest version). The index page loads fine, but when the user and password is posted, the upload page does not load and a timeout occurs.

With an old system running IE 6.0 I was able to call the upload page.

Has anybody got this problem as well and can give me a solution to it?

[Thomas K]

No ideas?

[AvaTar]

Not sure if ST is willing to provide support for free examples.

If I were you, I would get Wireshark and check were it fails.

[Thomas K]

They should. As an example can be an option to buy, the non-working result can be misleading.

I will try, had some unhelpful tests with wireshark on the new PC and Chrome already.

[waclawek.jan]

You did not care to tell us exactly which example are you talking about, so I took randomly [STM32Cube_FW_F4_V1.15.0]\Projects\STM324xG_EVAL\Applications\LwIP\LwIP_IAP\Src\ and in httpserver.c in http_recv() under the "process POST request for file upload and incoming data packets after POST request" comment I see something which I came across, too - and it may be one of the reasons why the example does not work - separate handling for "case of MSIE8 : we do not receive data in the POST packet" and "case of Mozilla Firefox : we receive data in the POST packet". The issue is, that there is a third option, namely, that not only the data don't start in the first packet, but also the HTTP header does not fit witin one packet. I saw this increasingly appearing with newer (especially "mobile") browsers, with bloated and often rather idiotic header items (which in the worst case split between packets freely).

This is a prime example where the realms of "big computers" and "small mcus" clash: the "big computers" world assumes infinite resources (processing power, data bandwidth, but here mainly memory), and also lives in the "permanent update" state. This is in direct contradiction with the mcu world, although the silicon vendors have strong incentive to push them towards the "big computers" world (and they do so with increasing success). Internet browsers are the forefront in the "unlimited assumption" league.

So the bad news is, that working against internet browsers is shooting at a moving target. The good news is, that going for fixing that yourself will teach you lots of the issues with web, you are going to need anyway, once you intend to make real use of it.

You may also go away towards the others who might be better in promising you instant solutions.

JW

[Thomas K]

Thank you, Jan!

I also have seen this line you mention. But your post clarifies to me, where the error could come from. I will have another look at it.