scottklement.com

Hi folks

i have an issue

in my pgm i have to call http_string

i call this procedure 3 times with same URl sale prm_data
http_string( 'POST': URL: prm_data: 'application/json');

for the first one , i have a 200 HTTP result and after a 404 http result

i dont understand why

Suppose you called up Dominos Pizza on the telephone and ordered a pepperoni pizza. Worked fine. Then you called the same number and ordered the same thing... and this time they said "we don't have pepperoni".

Would you then ask your telephone company what's wrong??!

I can't tell you why the HTTP server your connecting to would report "404" ("we don't have that url") when it previously reported "200" ("success"). Ask whomever runs the HTTP server.

It's true that when the server sends a 404, it sends it to HTTPAPI, and HTTPAPI sends it to your program. This is the same as when you call Dominos and you hear the person say "we don't have pepperoni" -- YES, you do hear it from your telephone. That doesn't mean that the problem is in the phone! It's just sending the voice that came from Dominos. Likewise, HTTPAPI never, ever, ever sends you a 404 code -- it doesn't even know how to generate a 404 code. It is simply telling you what the server told it.

Thanks Scott for the answer, I'm hungry now

Other question

There is always a longer call time of the "http_string( 'POST': URL: prm_data: 'application/json');" between the 1st time and the other times

There would be a way to make the first call faster ??

I imagine that this time is actually the opening of the communication port, once opened it is faster ???

I heard it was a java flaw

How it works
How to use this HTTP/2

So what's difference between the first and subsequent requests in traditional HTTP/1.1 scenario?

DNS Lookup: It might take more time to resolve DNS for the first request. Subsequent requests will resolve a lot faster using browser DNS cache.
Waiting (TTFB): The first request have to establish TCP connecting to the server. Due to HTTP keep-alive mechanism, subsequent requests to the same server will reuse the existing TCP connection to prevent another TCP handshake, thus reducing three round-trip time compared the first request.
Content Download: Due to TCP slow start, the first request will need more time to download content. Since subsequent requests will reuse the TCP connection, when the TCP window scaled up, the content will be downloaded much faster than the first request.
Thus generally subsequent requests should be much faster than the first request. Actually this leads to a common network optimization strategy: Use as few domains as possible for your website.

HTTP/2 even introduces multiplexing to better reuse a single TCP connection. That's why HTTP/2 will give a performance boost in modern front end world, where we deploy tons of small assets on the CDN servers.

Hi Scott , did you read my questions ???

OlivierPierre04 wrote: Fri Jan 21, 2022 8:37 am How it works
How to use this HTTP/2

HTTPAPI is an implementation of HTTP/1.1 -- it does not offer HTTP/2.

OlivierPierre04 wrote: Fri Jan 21, 2022 8:37 am So what's difference between the first and subsequent requests in traditional HTTP/1.1 scenario?

From HTTPAPI's perspective, there is no difference, it is doing the same thing both times.

OlivierPierre04 wrote: Fri Jan 21, 2022 8:37 am DNS Lookup: It might take more time to resolve DNS for the first request. Subsequent requests will resolve a lot faster using browser DNS cache.
Waiting (TTFB): The first request have to establish TCP connecting to the server. Due to HTTP keep-alive mechanism, subsequent requests to the same server will reuse the existing TCP connection to prevent another TCP handshake, thus reducing three round-trip time compared the first request.
Content Download: Due to TCP slow start, the first request will need more time to download content. Since subsequent requests will reuse the TCP connection, when the TCP window scaled up, the content will be downloaded much faster than the first request.
Thus generally subsequent requests should be much faster than the first request. Actually this leads to a common network optimization strategy: Use as few domains as possible for your website.

But, in general, I agree... DNS is probably the reason it's faster. This is not a part of HTTPAPI, however, but is a part of the operating system. The way it works is that the data gets cached after you look it up the first time, so the next time you do it, it'll already know the answer.

For example, the HTTP server that runs this forum is www.scottklement.com. When I purchased this domain and set it up on my DNS server, I gave it a "time to live" (TTL) of 3600 seconds (that's 1 hour). So if you were to use a URL beginning with http://www.scottklement.com (or https:// doesn't matter) most likely your computer doesn't know where www.scottklement.com is on the network, so it would ask the operating system's DNS resolver. That resolver would ask the .com DNS server who runs scottklement, and then ask the scottklement.com server what the address is for www.scottklement.com. So it has to communicate with multiple DNS servers to finally find out the IP address. This takes time -- but the good news is, once it has done it once, it'll remember it for 1 hour. So if you do 100 requests, the first one may be slower, but the other 99 will already know the address (provided they are made within 1 hour.)

Another way that the first request might be different is TLS (which people often refer to as "SSL", but SSL is obsolete). HTTPAPI sets up the secured sockets environment the first time, but then keeps it in memory, so subsequent requests won't need to set it up again unless the activation group gets ended. On my machine, the time this takes is VERY small, but it could be different on your machine, especially if yours is underpowered.

But, we don't have to guess... you can turn on performance logging in HTTPAPI and it'll show you what is taking the time.

OlivierPierre04 wrote: Fri Jan 21, 2022 8:37 am HTTP/2 even introduces multiplexing to better reuse a single TCP connection. That's why HTTP/2 will give a performance boost in modern front end world, where we deploy tons of small assets on the CDN servers.

You aren't writing a web browser, are you?! Are you trying to download multiple documents simultaneously? If not, this isn't going to make a difference.

OlivierPierre04 wrote: Fri Jan 21, 2022 8:11 am I heard it was a java flaw

HTTPAPI is written in RPG, not Java. How could it have a Java flaw?!