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.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
