Re: Question about oSession

1,486 views
Skip to first unread message

EricLaw

unread,
Feb 19, 2013, 11:54:54 AM2/19/13
to httpf...@googlegroups.com
actReissueSelected replays the currently selected sessions in the Web Sessions list. It's probably NOT a function that you would want to call inside an OnPeekAtResponseHeaders event handler, as it almost certainly isn't doing what you want. To your question, no, calling this function does not affect the current request in any way.
 
Can you please step back and describe what you're trying to accomplish at a higher level?
 
thanks!

EricLaw

unread,
Feb 20, 2013, 10:33:47 AM2/20/13
to httpf...@googlegroups.com
Sorry, but this is still far too low-level. What is the overall goal that you're trying to achieve here? What's the client application? What's the server application? Is the goal to mask server errors from the client so that it doesn't even know about them? Do you know why the server is erroring? What are the side-effects, if any, of the server receiving multiple copies of the original request? Must the client be oblivious to the fact that the server error'ed originally, or is it okay if it gets a redirect in the event of an error?

karen gosforth

unread,
Feb 20, 2013, 12:07:59 PM2/20/13
to httpf...@googlegroups.com
Thank you again Eric.

Sorry, I wasn't clear, your questions are a great help though...


"Is the goal to mask server errors from the client so that it doesn't even know about them?"

ans: Exactly, if the client knows about the error, then it will halt and I have no control over that.
---
"Do you know why the server is erroring?"

ans: no, I have no access there either. Fiddler is my only hope.
---
"What are the side-effects, if any, of the server receiving multiple copies of the original request?"

ans: no side effects, further, if there is a delay of seconds before original request reissue, the server responds 200 OK. Also, a max number of retries will be nice for the server.
---
"Must the client be oblivious to the fact that the server error'ed originally,"

ans: yes, completely, key goal.
---
"... or is it okay if it gets a redirect in the event of an error?"

definitely not, if it does it will halt which is the prime reason I'm looking at Fiddler.
---

tia
Message has been deleted

EricLaw

unread,
Feb 27, 2013, 11:16:42 AM2/27/13
to
This task is quite a bit trickier than one might hope. It's easy for Fiddler to replay requests that fail, but it's considerably harder for Fiddler to "automatically" replace the contents of an error response with that of another network request. It's even trickier to do this in the script engine.
 
But, Fiddler being Fiddler, almost anything is possible.
 
The first thing to recognize is that connection-related error messages generated by Fiddler never flow through OnBeforeResponse; instead they flow through the OnReturningError handler. So, your code needs to run there.
 
Uncomment the OnBeforeResponse function and add the following code:

static function OnReturningError(oSession: Session) {
  if ((oSession.responseCode != 502) && (oSession.responseCode != 504)) {
    return;
  }

  // If this request was a retry, don't replay it!
  if (!String.IsNullOrEmpty(oSession["X-RetryNumber"]))
  {
    return;
  }

  // We'll retry a maximum of four times
  for(var iRetry: int = 1; iRetry < 5; ++iRetry)
  {
    var oRetry = new RetryRequest;
    var newSession = oRetry.Retry(oSession, iRetry);
    if (200 == newSession.responseCode)
    {
       // If we were successful on a retry, bail here!
       oSession.oResponse.headers = newSession.oResponse.headers;
       oSession.responseBodyBytes = newSession.responseBodyBytes;
       oSession.oResponse.headers["Connection"] = "close"; // Workaround limitation
       break;
    }
  }
}
Then, at the bottom of the file, after the final closing brace } add this class:
 

class RetryRequest {
   private var oWaitForIt = new System.Threading.ManualResetEvent(false);     
   function Retry(oSession: Session, iRetry: int)
   {
     var oSD = new System.Collections.Specialized.StringDictionary();
     oSD["X-RetryNumber"] = iRetry;
     oSD["ui-Comments"] = ("Retry #"+iRetry+". Replaying Session #"+oSession.id);
     oSD["ui-Color"] = "green";
     var newSession = FiddlerApplication.oProxy.SendRequest(oSession.oRequest.headers, oSession.requestBodyBytes, oSD);
     newSession.add_OnStateChanged(fnCallback);
     oWaitForIt.WaitOne();
     return newSession;
   }

   function fnCallback(sender:Object, ea:Fiddler.StateChangeEventArgs)
   {
     if (ea.newState >= SessionStates.Done) oWaitForIt.Set();
   }
}

EricLaw

unread,
Feb 27, 2013, 11:35:41 AM2/27/13
to
Incidentally, this will be even easier in the next version, with the addition of a new SendRequestAndWait method.
 

static function OnReturningError(oSession: Session) {
if ((oSession.responseCode == 502) || (oSession.responseCode == 504)) return;


if (!String.IsNullOrEmpty(oSession["X-RetryNumber"])) return;

for(var iRetry: int = 1; iRetry < 5; ++iRetry)
{

   var oSD = new System.Collections.Specialized.StringDictionary();
   oSD.Add("X-RetryNumber", iRetry.ToString());
   var newSession = FiddlerApplication.oProxy.SendRequestAndWait(oSession.oRequest.headers, oSession.requestBodyBytes, oSD, null);

   if (200 == newSession.responseCode)
   {
      // If we were successful on a retry, bail here!
      oSession.oResponse.headers = newSession.oResponse.headers;
      oSession.responseBodyBytes = newSession.responseBodyBytes;

Reply all
Reply to author
Forward
0 new messages