views:

1530

answers:

12

The Setting:
The program in question tries to post form data via an AJAX call to a target procedure contained in the same package as the caller. This is done for a site that uses a secure connection (https). The technology used here is PLSQL and the DOJO JavaScript library. The development tool is basically a text editor.

Code Snippet:

function testPost() {

dojo.xhrPost( {
url: ''dr_tm_w_0120.test_post'',
form: ''orgForm'',
load: testPostXHRCallback,
error: testPostXHRError
});
}

function testPostXHRCallback(data,ioArgs) {

     alert(''post callback'');  
      try{  
      dojo.byId("messageDiv").innerHTML = data;  
      }  
      catch(ex){  
            if(ex.name == "TypeError")  
            {  
              alert("A type error occurred.");  
            }  
      }   
      return data;  
   }

function testPostXHRError(data, ioArgs) {

     alert(data);  
      alert(''Error when retrieving data from the server!'');  
      return data;  
   }

The Problem:
When using IE6 (which the entire user-base uses), the response sent back from the server is a 404 error.

Observations:
The program works fine in Firefox.
The calling procedure cannot target any procedures within the same package.
The calling procedure can target outside sites (both http, https).
The other AJAX calls in the package that are not posts of form data work fine.
I've searched the internets and consulted with senior-skilled team members and haven't discovered anything that satisfactorily addresses the issue.
*Tried Q&A over at Dojo support forums.

The Questions:
What troubleshooting techniques do you recommend?
What troubleshooting tools do you recommend for HTTPS analyzing?
Any hypotheses on what the issue might be?
Any ideas for workarounds that aren't total (bad) hacks?

Ed. The Solution
lomaxx, thx for the fiddler tip. you have no idea how awesome it was to get that and use it as a debugging tool. after starting it up this is what i found and how i fixed it (at least in the short term):

ef Fri, 8 Aug 2008 14:01:26 GMT dr_tm_w_0120.test_post: SIGNATURE (parameter names) MISMATCH VARIABLES IN FORM NOT IN PROCEDURE: SO1_DISPLAYED_,PO1_DISPLAYED_,RWA2_DISPLAYED_,DD1_DISPLAYED_ NON-DEFAULT VARIABLES IN PROCEDURE NOT IN FORM: 0

After seeing that message from the server, I kicked around Fiddler a bit more to see what else I could learn from it. Found that there's a WebForms tab that shows the values in the web form. Wouldn't you know it, the "xxx_DISPLAYED_" fields above were in it.

I don't really understand yet why these fields exist, because I didn't create them explicitly in the web PLSQL code. But I do understand now that the target procedure has to include them as parameters to work correctly. Again, this is only in the case of IE6 for me, as Firefox worked fine.

Well, that the short term answer and hack to fix it. Hopefully, a little more work in this area will lead to a better understanding of the fundamentals going on here.

+3  A: 

First port of call would be to fire up Fiddler and analyze the data going to and from the browser.

Take a look at the headers, the url actually being called and the params (if any) being passed to the AJAX method and see if it all looks good before getting to the server.

If that all looks ok, is there any way you can verify it's actually hitting the server via logging, or tracing in the AJAX method?

ed: another thing I would try is rig up a test page to call the AJAX method on the server using a non-ajax based call and analyze the traffic in fiddler and compare the two.

lomaxx
A: 

Lomaxx:
*Fiddler is for HTTP.
*Headers, url, params are all good
*Have to contact our corporate admins and see if they're feeling nice enough to look at the logs

happyappa
+1  A: 

Fiddler is for HTTP.

Interesting... on the front page it says:

Fiddler 2 has replaced Fiddler 1.x. Fiddler 2 supports debugging HTTPS traffic, a richer extensibility model, and can by installed side-by-side with Fiddler 1.x if desired. Note that Fiddler 2 requires version 2.0 of the .NET Framework.

I still reckon it's worth firing it up :)

lomaxx
A: 

Xenph Yan,

-Site's behind a firewall, so no link.
-The code is at work, inaccessible at the moment. It's just a DOJO XhrPost trying to send a form w/ the callback and error function set up in typical fashion. The call to the target results in the server sending back a 404 handled by the error function in the XhrPost function. I'll try to post a snippet tomorrow.
-Yeah, server, it's late. thx.
-Firebug lite doesn't work on this app. IEHTTPHeaders doesn't work either.
-HTTPPostLive doesn't get any Google hits. maybe it's late and I can't GIS either.

happyappa
A: 

Lomaxx,

Thx for the follow up.
I see the https part you referred to here.
The original link had different content.

I'll try to use this tomorrow...

happyappa
A: 

Xenph Yan,

FYI, posted a code snippet above. Thx again for the response so far.

happyappa
A: 

lomaxx -

thx for the fiddler tip. you have no idea how awesome it was to get that and use it as a debugging tool. after starting it up this is what i found and how i fixed it (at least in the short term):

ef Fri, 8 Aug 2008 14:01:26 GMT dr_tm_w0120.test_post: SIGNATURE (parameter names) MISMATCH VARIABLES IN FORM NOT IN PROCEDURE: SO1_DISPLAYED_,PO1_DISPLAYED_,RWA2_DISPLAYED_,DD1_DISPLAYED NON-DEFAULT VARIABLES IN PROCEDURE NOT IN FORM: 0

After seeing that message from the server, I kicked around Fiddler a bit more to see what else I could learn from it. Found that there's a WebForms tab that shows the values in the web form. Wouldn't you know it, the "xxx_DISPLAYED_" fields above were in it.

I don't really understand yet why these fields exist, because I didn't create them explicitly in the web PLSQL code. But I do understand now that the target procedure has to include them as parameters to work correctly. Again, this is only in the case of IE6 for me, as Firefox worked fine.

Well, that the short term answer and hack to fix it. Hopefully, a little more work in this area will lead to a better understanding of the fundamentals going on here.

happyappa
A: 

no problem, glad it helped. I haven't found anything that comes close to beating fiddler for analyzing the requests going to and from IE browsers yet.

lomaxx
A: 

@gary were you developing the server side as well or just the client? I have some SSL woes myself.

pc1oad1etter
A: 

pcloadletter -

@gary were you developing the server side as well or just the client? I have some SSL woes myself.

oh man, i checked out those woes you're referring to. well, in this context, i'm doing mostly client development with a mix of PLSQL, HTML, JavaScript, and a little Java. we have some shell and perl scripts that we run on the server, but i don't think that's what you're getting at.

we have corporate server admins who are responsible for admin stuff.

my team does do some stuff w/ PKI & CAC cards implementation...but that's outside my view. too bad those folks aren't using stack overflow...they'd probably have more insight on the ssl stuff you're dealing w/.

happyappa
+1  A: 

@gary

oh man, i checked out those woes you're referring to. well, in this context, i'm doing mostly client development with a mix of PLSQL, HTML, JavaScript, and a little Java. we have some shell and perl scripts that we run on the server, but i don't think that's what you're getting at.

we have corporate server admins who are responsible for admin stuff.

my team does do some stuff w/ PKI & CAC cards implementation...but that's outside my view. too bad those folks aren't using stack overflow...they'd probably have more insight on the ssl stuff you're dealing w/.

Yeah - my hope is just that because it is a niche question it doesn't get left behind (as so far no one has responded!). I added a couple of requests to help keep that from happening:

pc1oad1etter
A: 

So what was your solution exactly? :/

I'm getting issues grabbing the raw data through Fiddler.

I'm looking at maybe using a server side MSXML2.ServerXMLHTTP object to solve this issue.

  • DJ
Dan Jeffrey