Re: [xml] xmlSaveToFd: unexpected behavior while redirecting the 'stdout' stream to a file

Just to clarify the reason why I am using buffered IO only, I am currently coding a dynamic website that is 
written in the C language.
After compiling the C code, I upload the program to a web server (Apache).
On the web browser, when I try to access to the website, there is an error: Internal Server Error.
In the Apache logs I see: malformed header from script 'index.cgi': Bad header: <?xml version="1.0"?>.
So, I was wondering why I got a bad header whereas it was the first thing written by my program to the 
'stdout' stream.
Now, I have the answer: I need to use buffered IO only.

Remark: I don't know exactly how Apache is managing the CGI file but I guess it does something similar to 
redirecting the 'stdout' stream to a file because I get the same behavior when I try do that.

On Sun, 15 Apr 2018 11:33:51 -0700
"Eric S. Eberhard" <eric vicsmba com> wrote:

This is a 100% correct answer.  Why anyone on a modern computer would 
even used buffered anything except extreme cases is beyond me.  I know I 
cannot do better than AIX no matter how I code it.  Since I can write 
files of many gigs (and read them) ... I can no longer perceive a true 
need (except us old guys like to be efficient) for buffering.  The code 
would be simpler if ripped out.  Oh -- one can easily write say 500 meg, 
start a new file, etc -- and cat them all together.  I just think 2 gig 
XML is absurd.

We do have XML feeds that are indeed well over 2 gig.  And many customer 
could not parse it, read it, or whatever.  We found a simpler solution 
-- the files have two tags:\

<file_num> and <file_of> ... hence when I start to hit a (user defined) 
limit of say 500 meg, and I have already done the math ... they will get 
"<file_num>4</filenum><filenum_of>7</filenum_of> ... this allows 
unlimited file sizes to be accepted by all machines.  It also helps in 
file transport -- because if you are missing #3 -- just get #3.  We also 
no longer send any important XML in URLs ... we send:


And let the customer get it when they want.  We found once we changed 
that reduced the XML traffic by 2/3 (we do 2-4 million transactions per 
day so it really matters).  If there is an error getting the file, get 
it again. And again if needed.

Using date/time stamps is also important -- for example we send XML for 
order status.  We are FAST.  We can receive XML, print a pick ticket, 
pick it, ship it (all automated with baggers and boxers and label 
applicators),  rate shop, produce all shipping documents including 
invoice, update inventory, etc ... in minutes.  If the customer has 
"silly" software they expect each step.  We don't.  It is 
order_1234567.xml period.  Obviously if it is sitting on the UPS truck 
the odds are good we loaded the order, printed a picking ticket, packed 
it, invoiced, and placed on the UPS electronic manifest.  So date/time 
stamps can save a LOT of time.

Anyone that want help with a large interesting XML project or a small 
easy quick question is free to contact me.

Also -- please be CAREFUL with stdout and stderr .. 1>&2 1>filename.txt 
will get all the output, not just the "good" stuff.

Sorry, long answer :-)


On 4/4/2018 4:37 AM, Nick Wellnhofer wrote:
On 04/04/2018 13:28, YuGiOhJCJ Mailing-List wrote:
In order to use buffered IO only, I am now using the 'xmlSaveFile' 
function (instead of 'xmlSaveToFd'):

However, with this solution, I loose the 'options' parameter that was 
available with the 'xmlSaveToFd' function.
Is there a similar solution with the 'options' parameter please?

You can use xmlSaveToFilename with "-" as filename. There's also 
xmlSaveToIO taking custom IO callbacks.

xml mailing list, project page
xml gnome org

Eric S. Eberhard
2933 W Middle Verde Road
Camp Verde, AZ  86322

928-567-3727  work                      928-301-7537  cell             (our work)     (fun pictures)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]