Re: YAJL

Scott Klement <[email protected]> Tue, 18 Oct 2022 17:07:06 -0500
Newsgroups gmane.comp.systems.as400.web
Message-ID <[email protected]>
My best guess, based on your description, is that whatever is calling 
the API is using the HTTP 1.0 protocol.  This protocol, which was 
published in 1996, did not offer the "chunked" transfer coding.  That 
would also explain why "Connection: close" is in your header info -- it 
is telling it to keep receiving until the connection is closed.

Starting with HTTP 1.1  (originally published in 1997, but didn't become 
mainstream until further revisions were made in 1999) the chunked 
transfer coding is part of the core concepts of this protocol.  One 
important idea in 1.1 is to keep the connection open for multiple 
transfers, because it reduces the overhead of negotiating a new TCP 
channel (and frequently TLS parameters as well.)   1.1 is absolutely 
ubiquitous, although it's gradually being replaced by HTTP/2, it is 
still by far the most widely used HTTP version.

My guess is that whatever is calling your API is still using 1.0, which 
didn't support chunked coding -- that's weird, I haven't seen a client 
still using this older protocol in well over a decade, but I'm sure they 
are still out there.  But it perfectly fits your description.

So -- if the server allows you to specify the content-length header, 
that should solve the problem for you.   (However, in my experience, 
many HTTP servers don't allow it -- they discard the content-length, 
since they consider it their responsibility to establish this, not the 
application's responsibility.  They also often handle CCSID translation, 
which can change the length of the content.)

If adding content-length is working for you, I guess it's a good 
compromise for now.  I would strongly recommend updating the caller to 
use 1.1 or newer, though.  1.0 is well over 20 years out of date.


On 10/18/2022 3:39 PM, [email protected] wrote:
> I don't know where the chunk data processing problem is but...
>
> I created another version of yajl_writeStdout that included the Content-length: parameter in the header and it is now returning just the JSON data.
>
> No more chunk data.
>
> -----Original Message-----
> From: Scott Klement <[email protected]>
> Sent: Tuesday, October 18, 2022 12:45 PM
> To: Web Enabling the IBM i (AS/400 and iSeries) <[email protected]>; [email protected]
> Subject: Re: [WEB400] YAJL
>
> They aren't "extra" they are part of the HTTP protocol, it is telling the HTTP client how many bytes need to be received.
>
> It should not be included in the data that you process -- they are there just to tell the HTTP program how to receive the data, it should not be including them in the actual downloaded result. Something is wrong with the HTTP client that is calling out to the Apache.
>
> On 10/17/2022 9:25 PM, [email protected] wrote:
>> The program that is receiving the data is expecting pure JSON data to be returned.  Instead is it receiving these extra bytes prior to the first { and is abending.
>>
>>
-- 
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.