Loading ...
Sorry, an error occurred while loading the content.

Re: Understanding browser connections & server jobs

Expand Messages
  • andrew_david_kerr
    Scott, Thanks a lot for your clear explanation. That helps a lot in understanding the process. I am really enjoying trying things out with this excellent tool
    Message 1 of 4 , Dec 1, 2005
    • 0 Attachment
      Scott,

      Thanks a lot for your clear explanation. That helps a lot in
      understanding the process. I am really enjoying trying things out
      with this excellent tool (CGIDEV2), but it represents quite a
      different way of thinking at times!

      And 'yes' I am using UserID %%CLIENT%%.

      And thanks also to 'M'. Although the job shows up as having user
      QTMHHTTP, if you look at 'Current User Profile' that is where you
      find the 'real' profile. And I am not using 'persistence' at the
      moment.

      Andrew

      --- In Easy400Group@yahoogroups.com, Scott Klement <easy400@s...>
      wrote:
      >
      >
      > > I have added authorisation directives to my Apache config, so that
      > > the calling of CGI programs requires the entry of
      profile/password.
      > [SNIP]
      > > Since the authorisation change, the server jobs have the current
      user
      > > profile as the profiles of those users that have made requests.
      >
      > That sounds like the behavior of
      > UserID %%CLIENT%%
      >
      >
      > [SNIP]
      > > Now another user logs in, repeating the above process. It does
      not re-
      > > use `my' server job but spawns another with their profile.
      > >
      > > This implies a sort of `persistence' that I thought did not exist
      > > with the browser
      >
      > It has nothing to do with the browser, it's entirely on the server.
      It
      > tries to reuse jobs if it can because it's faster than spawning new
      ones.
      > If the existing ones are using a different user profile, however,
      for
      > security reasons, it won't reuse a job from a different user.
      (There
      > could be stuff lingering from that last user that the new user
      shouldn't
      > be authorized to. For example, if there's something already in
      memory from
      > when the job ran under QSECOFR, it could be sent to an ordinary
      user that
      > logs on next... To prevent that sort of security hole, it spawns a
      new job
      > when the userid changes.)
      >
      >
      > > Each time that I re-log back in I am guaranteed to get the same
      server
      > > job? This would have benefits in terms of library list setting,
      creating
      > > objects in QTEMP for reuse etc.
      >
      > No, you're not guaranteed. If something crashes, the server job
      could be
      > stuck at MSGW or could end, and then you'd get a new job. If you
      try run
      > two CGI scripts at once (for example, if loading a page with
      different
      > frames where more than one frame is provided by a CGI program)
      it'll
      > create a 2nd job for your userid. Or, the same user might be
      logged on to
      > more than one browser on more than one computer.
      >
      > Also, I believe that Apache shuts down unused jobs after a period
      of time.
      > Not sure, though.
      >
      > So, in the end, you can't rely on having the same job for each
      request. It
      > probably holds true 90% of the time, but you don't want to write
      software
      > that relies on it, so the behavior really doesn't do you any good.
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.