|
From: | jochen |
Subject: | Re: [lwip-users] Slow HTTP put request |
Date: | Mon, 26 Mar 2018 14:27:30 +0200 |
User-agent: | 1blu Webmail |
Speaking of that, why do you use PUT anyway? I would have used POST to implement what you seem to do. PUT seems rather "unusual" to me...
I thought PUT - because of its history? - is the right thing to send binary data to a server e.g. for firmware update. And a PUT header seems to be easier to create and decode than a POST multipart header. But yes, regarding the article in the previous post labview PUT seems to be unusual and POST seems to be better supported on labview. I'll try to check this out.
I don't know how that client knows about the version of the remote server. It can issue a first request to get the server's version, but that seemsrather unusual, too. And from your traces, that doesn't happen...But you can try to just make the server report "HTTP/1.0" in every responseinstead of "HTTP/1.1" and see what happens...
Regarding the PUT problem labview obviously doesn't care about my HTTP 1.0 replies and still requests expect/continue handing from the server otherwise the server is punished with a second delay. Maybe there is a labview configuration option for HTTP 1.0 ?
BTW: curl wants "HTTP/1.0 100 Continue\r\n\r\n" in the reply. "HTTP/1.0 100 Continue\r\n\" leads to confusion.
[Prev in Thread] | Current Thread | [Next in Thread] |