Re: [lwip-users] Slow HTTP put request

[jochen]

> 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 
> seems
> rather 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 
> response
> instead 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.