Views triggering twice
Jeff Gentry
series of related apps, working off of the same settings.py file (there's
a global urls.py, which triggers off of the first string and sends to a
subdirectory w/ it's own urls.py/__init__.py/models.py/views.py/etc. With
one exception (see below), any URL I send will call the resulting view
twice.
The one exception is that I'm using a heavily modified take off of the
djikiki wiki software, and it doesn't happen here.
My first thought was that it had to do w/ something in the template, but
replacing the template with a simple blank file the view still gets
triggered twice.
Then I noticed that the app based off of the djikiki setup was not doing
this, and I looked at what I had there but didn't notice anything that
would cause the difference.
Was hoping that someone might have an idea here as to what might be going
on.
-J
Jeff Gentry
Actually I lied a little bit - a completely blank file doesn't trigger
this (I can also seem to put in a <html> and </html> tag), but adding
anything else will cause the view to be loaded 2x.
Alex Koshelev
Jeff Gentry
I noticed that the URLs were displaying twice in the devel server console
(and in HTTP logs for when running off of apache). For the former case, I
put a print statement in the view function - when loading those pages, the
print is triggered twice.
The main reason I noticed it was that one particular view is fairly CPU
intensive and I was lookign at ways to optimize it a bit - on my CPU
tracker I noticed that every time I ran it I'd get two identical spikes,
so this code is definitely being run 2x.
Jeff Gentry
Another piece of info, in case it's useful here - the page does *not*
render on the first view call, it's only after the second call that the
page will render. I don't think it's even pulling up the template until
the second go-around, as a test I put some intentionally bad template code
in a template. On the first time the view was called, nothing happened
but on the second one I got the TemplateSyntaxError.
Malcolm Tredinnick
Quoting from the book of "if you hear hoofbeats, think horses, not
zebras": This obviously isn't normal Django behaviour and since calling
views is easily the most common operation in Django, it's safe to assume
that any breakage here in Django would have been noticed by other
people. Which means the problem is almost certainly in your code. None
of which you have shown us and we can't guess what it might contain.
Please create a very small example -- say a single URL pattern and a
view with one line it calling render_to_response() that demonstrates the
issue reliably. Then we might be able to work out what's going on.
I'm not entirely convinced by your diagnosis of rendering, since if the
browser was requesting the page twice, you might well not see the first
rendering at all. You could try printing things like the output of
traceback.print_stack() in your view to see if it's called the same way
both times, for example.
In any case, reduce you problem to the shortest possible example so that
you can show us the code. Although, typically, reducing it to the
shortest possible example more or less naturally reveals what the
problem is in the first place, because you end up seeing which line is
critical to triggering the issue at hand.
Regards,
Malcolm
Jeff Gentry
> zebras": This obviously isn't normal Django behaviour and since calling
> views is easily the most common operation in Django, it's safe to assume
> that any breakage here in Django would have been noticed by other
> people. Which means the problem is almost certainly in your code. None
> of which you have shown us and we can't guess what it might contain.
Oh, I'm fully expecting that it's something that I'm doing, didn't mean to
imply it was a Django issue. I was hoping that it was an obvious enough
screw up though.
I'm attaching a tarball, which immitates my setup in a minimal
fashion. At least when running on my system, the following browser
request triggers this behavior:
> rendering at all. You could try printing things like the output of
> traceback.print_stack() in your view to see if it's called the same way
> both times, for example.
I didn't see any differences in the two outputs.
> shortest possible example more or less naturally reveals what the
> problem is in the first place, because you end up seeing which line is
> critical to triggering the issue at hand.
Unfortunately, it didn't work here - I've got a view that only calls a
template, and a template which is almost completely empty.
Enrico
Check the HTML source on the browser and look for any empty "src" for
images or "href" for stylesheets.
If you find any, this may be the culprit of the second request, as the
browser tries to load the same view when looking for the image src or
stylesheet href...
Maybe this is why the blank file doesn't triggers twice...
Good luck!
Malcolm Tredinnick
On Fri, 2008-11-14 at 13:58 -0500, Jeff Gentry wrote:
[...]
> I'm attaching a tarball, which immitates my setup in a minimal
> fashion. At least when running on my system, the following browser
> request triggers this behavior:
>
> http://servername/test/
>
> > rendering at all. You could try printing things like the output of
> > traceback.print_stack() in your view to see if it's called the same way
> > both times, for example.
>
> I didn't see any differences in the two outputs.
>
> > shortest possible example more or less naturally reveals what the
> > problem is in the first place, because you end up seeing which line is
> > critical to triggering the issue at hand.
>
> Unfortunately, it didn't work here - I've got a view that only calls a
> template, and a template which is almost completely empty.
You didn't quite reduce it to the smallest possible example. However, it
was a good start and your example was small enough that it only took a
couple of attempts to find the problem. For the record, here's more or
less a verbatim transcript of what I did:
(1) Quick read through the files, nothing obvious showed up in the urls,
view or template.
(2) Ran manage.py and verified that the page loaded in the browser.
Twice. So the problem is repeatable on something other than your system
(always a relief).
(3) Removed the use of request context from the call to
render_to_response() in the view, since that was superfluous. Nothing
changed.
(4) Ran "curl -i http://localhost:8000/test/" to see what the headers
looked like and see which end of the transaction was doing the second
request. The headers looked normal (could have checked this in the
browser too, via Firebug). It also loaded the page only once, which
meant the problem was triggered by the browser.
(5) Checked the HTML that was returned by curl (that was why I used "-i"
and not just "-I"), since it's now clear that the returned HTML contains
the problem and noticed the error on the second attempt.
You're using the deprecated "background" attribute on the body element.
The description of "background" from the HTML spec (section 7.5.1 -- the
body element) says
The value of this attribute is a URI that designates an image
resource.
Note that it's a URI. That means something that is retrieved. Since
you've used the value "#fff", that will be interpreted by the browser as
a reference to the current page (#fff being an anchor, and not passed to
the server). Ergo, a second request is made.
The moral is (again) "don't put style elements in your HTML", I
guess. :-)
Regards,
Malcolm
Steve Holden
[...]
> (5) Checked the HTML that was returned by curl (that was why I used "-i"
> and not just "-I"), since it's now clear that the returned HTML contains
> the problem and noticed the error on the second attempt.
>
> You're using the deprecated "background" attribute on the body element.
> The description of "background" from the HTML spec (section 7.5.1 -- the
> body element) says
>
> The value of this attribute is a URI that designates an image
> resource.
>
> Note that it's a URI. That means something that is retrieved. Since
> you've used the value "#fff", that will be interpreted by the browser as
> a reference to the current page (#fff being an anchor, and not passed to
> the server). Ergo, a second request is made.
>
> The moral is (again) "don't put style elements in your HTML", I
> guess. :-)
>
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Jeff Gentry
> you've used the value "#fff", that will be interpreted by the browser as
> a reference to the current page (#fff being an anchor, and not passed to
> the server). Ergo, a second request is made.
Wow, thanks. Just reading through your step by step taught me some things
I didn't know :)
> The moral is (again) "don't put style elements in your HTML", I guess.
> :-)
Yeah, I'm not sure why I was doing that (in fact, I have the color issued
as part of the site-wide CSS), and I suspect I would have continued to
overlook that over and over and over again. Erg ... but thanks.
-J
Fangzx
above, I solved the problem.
It caused by the following line in my html template:
<link rel="stylesheet" type="text/css" href="#" id="css-patch"/>
I replaced with:
<link rel="stylesheet" type="text/css" href="/media/css/ie-patch-
blank.css" id="css-patch"/>
Thanks for all.
