I tool Malcolm's advice and looked closely at the packets going back
and forth. Upon pressing an input button nested within an anchor,
Firefox was sending two identical requests to the server, thus causing
my code to be executed twice. It seems that after the server responded
to one of the requests, the socket was closed and the second request
threw a broken pipe exception.
I am still not sure why Firefox sends two requests. At first I though
it was because Firefox was pre-fetching links, however, Firefox
documentation claims that links with URL parameters are not pre-
fetched. Also, there was no traffic over the wire before I pressed the
input button.
The problem seems to be with the way Firefox (and BTW Camino as well)
handles input buttons nested in anchor tags. Again, this does not
seems to be an issue with Safari or IE6. Is this an HTML folly that
I'm just not aware of?
<!-- Does NOT work -->
<a href="/session/drive/?sid={{ sid }}&pname={{ pname }}">
<input type="button" name="buttonLabel"
value="{{ parameters.buttonLabel }}" class="buttonBig" />
</a>
The following two alternatives are working just fine for me. Firefox
sends only one request, I don't get broken pipe errors, and my view
function is run only once.
<!-- Does work! -->
<a href="/session/drive/?sid={{ sid }}&pname={{ pname }}">
{{ parameters.buttonLabel }}
</a>
<!-- Does work! -->
<form action="/session/drive/" method="get" accept-charset="utf-8">
<input type="hidden" name="sid" value="{{sid}}" id="sid" >
<input type="hidden" name="pname" value="{{pname}}" id="pname" >
<input type="submit" name="buttonLabel"
value="{{ parameters.buttonLabel }}" class="buttonBig" >
</form>
Thanks Malcolm and Veged for your responses.
The Django template code above is also available here:
http://dpaste.com/hold/10611/
On May 6, 7:18 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2007-05-06 at 19:09 -0700, Jon Lesser wrote:
> > Hello Djangites:
>
> > I am having a hell of a time debugging this issue. Any help would be
> > most appreciated. If fact to sweeten the pot, I'll gladly paypal $2.00
> > to anyone with a solution.*
>
> > The short of it:
>
> > I have a view function called driveSession. From what I can determine
> > with print statements, all the lines of my view function are executing
> > without incident. The problem is that instead of redirecting (via
> > HttpResponseRedirect), abrokenpipeerror is barfed out to the
> > development server's console and the view function is executed a
> > SECOND time. On the second pass, all the function's lines are executed
> > again the redirect works just fine.
>
> > The Twist:
>
> > This only occurs with firefox 2.0.0.3 on Mac and Windows (haven't
> > tested previous versions of FF). Safari on Mac and IE 6 on Windows
> > never encounter thebrokenpipeerror and never execute the
> > driveSession view function more than once per request. In other words,
> > I only have this problem with Firefox.
>
> > About driveSession:
>
> > I am working on an application for administering social experiments at
> > UC Berkeley. The experiments are made up of components. When an
> > experiment participant finishes a component, the driveSession function
> > figures out what component they need to do next and redirects the
> > participant to the "kickoff function" for that component.
>
> > Code links:
>
> > TheBrokenpipe(error:32) traceback is here:http://dpaste.com/hold/9757/
> > DriveSession code is here:http://dpaste.com/hold/9755/
>
> The location of the error and the fact that only some browsers raise it
> (and consistently at that) suggests that for some reason the browser is
> not listening to the (full?) response.
>
> To debug this in depth you are probably going to have to look at the
> network traffic between the browser and the server and try to work out
> why the browser is closing its end of the connection. Which tools to use
> and how easy this will be will depend on your experience and platforms
> (I don't use Windows or Macs, so I'm not familiar with all the
> possibilities there). If I was debugging this, I would fire up WireShark
> (which is at least available for both Windows and Macs) and capture all
> the traffic going to and from port 8000 (the dev server's port) for a
> single exchange. The examine the TCP conversation (an option in
> WireShark) and try to work out when the browser gives up the ghost. No
> guarantees that that will reveal any information you can use, but it
> should at least confirm where the problem lies.
>
> You might also examine an exchange of request/responses that works (e.g.
> on Safarai or IE6) and compare and contrast to figure out where the
> successful and unsuccessful attempts start to differ.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
