Re: Help with HTLoadAbsolute...

Henrik (et al.):

First a little reminder on what this thread is about...

  I'm building a GUI-less client using the newPreemptiveClient.  The
  client needs to talk SSL.  I have code that works if I use
HTLoadToFile
  to fetch the URL but that breaks if I use HTLoadAbsolute instead. 
Given
  that HTLoadToFile ends up calling HTLoadAbsolute, I'm a bit confused.

  What HTLoadAbsolute seems to be doing is reading one chunk and then
  quitting.  (I'm talking to a 1.1 server over SSL)  Does anyone have
any
  suggestions as to where I should be looking for the problem?  I have a
  sneaking suspicion it has to do with the stream stack that's setup but
  since I really don't know what's going on that may be a red herring.

I don't pretend to understand what's _really_ going on, but I've found a
fix.  It suggests that something else isn't quite right.  What I didn't
mention above was that I was testing things in a GUI-based app first.

After much head-scratching, I ended up creating two versions of the
secureget program.  One was console-based and the other GUI-based.  I
factored out the original contents of main() and called that same code
from both apps.  It turns out the code would work in the console app but
not in the GUI app.

The two apps seemed to diverge in HTSaveLocally() when creating a file
for output.  The GUI app had a null stdin or something, resulting in the
use of HTErrorStream instead of a file stream.  I created a callback for
the HT_A_PROMPT/HT_MSG_FILENAME pair that returned a valid file name and
presto, the GUI-based app worked.  (I'm guessing this is similar to the
reasons that HTLoadToFile worked as well.)

The fix works for me but it suggests that something else (out of my
realm of understanding) is broken.  I leave the solution as an exercise
to the reader.  (I can provide my code on demand but I didn't think I'd
make this message any longer for now...)  I'd prefer that no extra file
need to exist.  (Is this a function of compiling a Debug configuration?)

thanks,
Marco

Received on Tuesday, 20 July 1999 20:05:51 UTC