Protocol is irrelevant in the case I mentioned as the xss checker I
had this experience with checked the url, not the content itself.  the
environment I worked with was very different (iPlanet, WebSphere, SSO
via netegrity, load balanced mid-tier servers, solaris, etc.).  The
important point to note is anything that sits between the client and
whatever services the request can interrupt the request:
- web server
- web server plugins (security plugins, etc.)
- servlet container plugins (isapi plugin, etc.)
- servlet container

Chances are something in the stack is failing and/or blocking the
request.  Somewhere in the logs for each piece in the stack should
provide the source of the problem.  There is some limited debugging
you can do from the client side for these types of things.  Firebug
for Firefox and Fiddler for IE come to mind.  These can at least point
you in a direction to chase.

Axton Grams

On Thu, May 1, 2008 at 10:27 AM, Craig Carter
<[EMAIL PROTECTED]> wrote:
> Hi Axton,
>
>  This is actually all https and the web site is anonymous access
>  (standard IUSR account) so ServletExec "should" be available to any
>  request.  Wouldn't all requests to ServletExec come through using the
>  standard https protocol?
>
>  Craig Carter
>
>
>  -----Original Message-----
>  From: Action Request System discussion list(ARSList)
>
> [mailto:[EMAIL PROTECTED] On Behalf Of Axton
>  Sent: Thursday, May 01, 2008 8:13 AM
>  To: arslist@ARSLIST.ORG
>
>
> Subject: Re: Q: Underlying Specifics - Data Connection
>
>  Also, anything that blocks an http request to servlet x will cause
>  this error.  I've seen this happen when an xss plugin on the web
>  server disallowed certain requests.
>
>  Axton Grams
>
>  On Thu, May 1, 2008 at 9:33 AM, Garrison, Sean (Norcross)
>  <[EMAIL PROTECTED]> wrote:
>  > **
>  >
>  >
>  >
>  > Is all this running on one server or do you have multiple "Servlet
>  Exec"
>  > servers or IIS Servers?  Are you running anything like this:
>  >
>  >
>  >
>  >                                                                  Web
>  Server
>  > A
>  > Servlet Exec  A
>  >
>  > Firewall -->Load Balancer------>
>  Firewall
>  > ------>Load Balander---->
>  >
>  >                                                                  Web
>  Server
>  > B
>  > Servlet Exec  B
>  >
>  >
>  >
>  > If you do "Web Server A" could have a session to "Servlet Exec A" and
>  then
>  > magically switch to B in the middle of a transaction and cause this
>  error to
>  > occur.  If I understand right this error has to do with the
>  connectivity
>  > between the "Web Server" and the "JSP Engine" whatever that might be
>  (in
>  > your case it is Servlet Exec).  There may be a timeout setting on your
>  web
>  > server that is causing this issue to occur.  If you connect directly
>  to
>  > "Servlet Exec" then you probably won't get this error.  I am assuming
>  you
>  > are running Apache or IIS for you web server ... so it may be a
>  timeout
>  > setting on the connection between the web server and servlet exec.
>  >
>  >
>  >
>  > Hope that helps ...
>  >
>  >
>  >
>  > Thanks,
>  >
>  >
>  >
>  > Sean
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > From: Action Request System discussion list(ARSList)
>  > [mailto:[EMAIL PROTECTED] On Behalf Of Craig Carter
>  >  Sent: Thursday, May 01, 2008 8:34 AM
>  >  To: arslist@ARSLIST.ORG
>  >  Subject: Q: Underlying Specifics - Data Connection
>  >
>  >
>  >
>  > **
>  >
>  >
>  >
>  > We've been experiencing an intermittent connection error for the past
>  couple
>  > of years and it is something we really need to try to resolve.  By
>  > intermittent, the application works great for everyone most of the
>  time but
>  > occasionally, the following error pops up:
>  >
>  >
>  >
>  > "Unable to set up a data connection, which is preventing the
>  application
>  > from working correctly. (ARERR 9351)"
>  >
>  >
>  >
>  > We're behind some firewalls and this pops up in a browser session
>  while
>  > performing a save and/or performing a retrieval of information.  Our
>  midtier
>  > is located a couple thousand miles away from our database server and
>  the
>  > midtier and database are set to use a specific port.  Our assumption
>  is that
>  > at that moment, there is a brief connectivity problem that causes
>  > this-especially since it appears more often at certain offsite
>  locations
>  > that at others.
>  >
>  >
>  >
>  > We have submitted a ticket to BMC since the error guide simply adds
>  "An
>  > internal error occurred during a back channel request from the browser
>  to
>  > the mid tier server."
>  >
>  >
>  >
>  > I'm basically looking for anyone who might have more information on
>  what
>  > underlying problem would cause this specific message?  What kind of
>  back
>  > channel request?  It is related to something specific that we could
>  possible
>  > code around?
>  >
>  >
>  >
>  > Any ideas are appreciated.  I'll be turning on all of the logs and
>  looking
>  > for an answer but wanted to tap the combined expertise for possible
>  > remedies...
>  >
>  >
>  >
>  > ARS 7.0.1 P5
>  >
>  > Windows Server 2003
>  >
>  > ServletExec 5 AS
>  >
>  > Java 1.5.0_15
>  >
>  > SQL Server 2005
>  >
>  >
>  >
>  > Craig Carter
>  >
>  > Software Engineer, RSP
>  >
>  >
>  >
>  >
>  >
>  > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>  > html___
>  >
>  >  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers
>  Are"
>  > html___
>
>  ________________________________________________________________________
>  _______
>  UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
>  
> _______________________________________________________________________________
>  UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>
>
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to