TL;DR - The Wiced HTTP server deals with requests incorrectly, expecting the entire request to be contained within one TCP packet. This is not always the case, especially with HTTP POSTs with a body of data, which may be split off into a second packet. The issue is confirmed on the Broadcom lists here.
As I mentioned in another post, I’ve been working on a React Native configuration app for our product’s prototypes, which we’d like to deliver to potential customers with a user-friendly interface for setting up wifi.
After a few days’ work, I managed to get an Android device configuring a Photon and fully expected the same app to work on iOS, but to my dismay it did not. Since the configuration step is just an HTTP request being fired from a JS environment, I was wary of the CORS issues mentioned in the very active “Photon softAP usage?” thread, but that turned out to be a red herring.
My attempts to packet sniff the underlying difference between iOS and Android were thwarted because they looked identical in Wireshark…that is, until I finally noticed my iOS request was getting split between header and body into two packets. Going deeper into the rabbit hole revealed the failure to be in how internal WICED server handles HTTP requests.
Turns out: not very well. According to this line in the server code, requests are logically split on a packet-by-packet basis rather than as proper HTTP data streams. This explained why my iOS request was being returned a “successful” {r:0} response - the server was considering the posted data as a separate request! As a side note, this is exactly why I posted here about improving the configuration API to have better error handling, and possibly even provide a way to verify credentials before attempting connection.
The relevant confirmation of this issue can be found here: https://community.broadcom.com/message/14450#14450 . Unfortunately, there doesn’t seem to be a push to fix the behavior, but perhaps Particle can put some pressure on them?