Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By dnts
#69703 Problem solved. After turning on debug flags in the ESP webserver parsing.cpp source I managed to pinpoint the issue. It has to do with lower and upper case letters in the 'Content-Type' header. Seems like most servers are not particular with lower and upper case so my code ran fine on all but the ESP which uses direct string compare and hence is case sensitive. After fixing the header string, my javascript code runs just fine.
Here it is for the sake of next generations:
Code: Select allfunction uploadfile(flname,data)
{
    var boundary = "----WebKitFormBoundarygqk86ALR3dpFbAaF";
    var xhr = new XMLHttpRequest();
    var body = '--'+ boundary + '\r\n'+'Content-Disposition: form-data; name="MAX_FILE_SIZE"\r\n\r\n100000\r\n'+'--' + boundary +'\r\n'+'Content-Disposition: form-data; name="uploadedfile";'+ 'filename="'+flname+'.xml"\r\n'+ 'Content-Type: text/xml\r\n\r\n'+ data + '\r\n'+ '--'+boundary + '--\r\n';

    xhr.open("POST", "/edit", true);
    xhr.setRequestHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"  );
   xhr.setRequestHeader(
        "Content-Type", "multipart/form-data; boundary="+boundary
    );
   
    xhr.onreadystatechange = function ()
    {
        if (xhr.readyState == 4 && xhr.status == 200)
            alert("File uploaded!"+xhr.responseText);
    }
    xhr.send(body);
   }
   

The function takes two variables - flname is the filename without extention - I've added '.xml' in my code. The data var is the content of the file to be uploaded.
If anybody wonders, the Boundary variable is just a random string used to delineate the block into parts.
The rest of it is quite straightforward (once it works).
User avatar
By tele_player
#69709 Interesting.

It's a bug in the ESP server code, since the header field names are case-insensitive, per the HTTP RFC's.

A subtle difference that you missed in the Wireshark traces, probably hidden by Wireshark protocol decoding, but noticeable in the hex output.
User avatar
By dnts
#69711
tele_player wrote:Update: this bug was fixed almost exactly one year ago, according to github.

Are you using an old copy of the library?

I'm on 2.3.0 for as long as it exists... so I'm supposed to be up-to-date. I figured this might be a bug but hey - 2.3.0 - doesn't get any more recent than that (if you don't care for beta versions).
Can you share a link to the bug description?
Thx.