> 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.
I guess you mean curl wants "HTTP/1.1 100 Continue\r\n\r\n"; and that is
because 100 Continue belongs to the 1.1 spec, there is no such thing on
the HTTP specification 1.0
_
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 t
joc...@strohbeck.net wrote:
> [..]
> Regarding the expect/continue overhead, according to wireshark trace
> below it is about 30ms extra - way to much for what I intended to use
> PUT (write a couple of bytes to twi interface).
Speaking of that, why do you use PUT anyway? I would have used POST
I see the following solution: - server sends reply to expect/continue
and then... well, frankly don't know exactly what happens then and how
much overhead this means [..]
I see 2 solutions: implement a HTTP 1.1 server that keeps to the
specification (I'll have to do that for the lwIP httpd, too
joc...@strohbeck.net wrote:
> I see the following solution:
> - server sends reply to expect/continue and then... well, frankly don't
> know exactly what happens then and how much overhead this means
> [..]
I see 2 solutions: implement a HTTP 1.1 server that keeps to the
specification (I'll have
You should capture the traffic on your customer premises to make sure
this is what's happening. I'm curious to know.
Below is the trace of our customer. I think if you look at packets
around no 2552 for example it shows the same behavior as curl in my
understanding. Labview is waiting with a 1
> Try `curl -H "Expect:"` to remove it, or even `curl -0` to fallback to
> HTTP1.0; but it won't help in your real life scenario. We don't know if
> that is what happens on your customer side.
Works like a charm!
> You should capture the traffic on your customer premises to make sure
> this is wh
Sergio R. Caprile wrote:
>You should capture the traffic on your customer premises to make sure
>this is what's happening. I'm curious to know.
You could also implement handling the Expect header in your http server and see
if this speeds up the transfer.
Simon
___
Yeap, the 100-continue issue explains what you see on your local tests.
This "issue" with curl is known, and certainly not its fault.
https://curl.haxx.se/mail/lib-2017-07/0013.html
Try `curl -H "Expect:"` to remove it, or even `curl -0` to fallback to
HTTP1.0; but it won't help in your real life s
On 24.03.2018 07:26, joc...@strohbeck.net wrote:
[..]
Attached is the pcap file. All I can tell is that the header and payload
is split into 2 packets and using curl and labview the 2nd packet is
received after a huge delay. I tested --no-delay and --no-buffer and
added manually keep-alive to the
Am 23.03.2018 21:10, schrieb goldsi...@gmx.de:
On 23.03.2018 20:50, Jochen Strohbeck wrote:
[..] I am able to reproduce the same problem using curl on windows and
found out that even a PUT request with only a single byte payload
takes about a second! If I do the same request with python it ta
On 23.03.2018 20:50, Jochen Strohbeck wrote:
[..]
I am able to reproduce the same problem using curl on windows and found
out that even a PUT request with only a single byte payload takes about
a second! If I do the same request with python it takes some
milliseconds. Why?
I guess the problem is
Sorry for the dumb subject but I don't know better...
I implemented a HTTP server using the netconn API on a SAME70 board and
tested ethernet communication using python scripts. Now our customer did
the same with labview on windows and the communication is slow
especially using PUT requests.
I am
13 matches
Mail list logo
