Monday, January 29, 2018

Re: Views triggering twice

Malcolm,
 i'm seeing the same issue of my page loading twice. working on top of something my previous colleague built.  i see "background" element when i do curl. 
I dont see this in any of my HTML files. I'm sure that i'm looking at the wrong place. 

This is my curl response: 
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <title>Page not found at /api/rest/apps/</title>
  <meta name="robots" content="NONE,NOARCHIVE">
  <style type="text/css">
    html * { padding:0; margin:0; }
    body * { padding:10px 20px; }
    body * * { padding:0; }
    body { font:small sans-serif; background:#eee; }
    body>div { border-bottom:1px solid #ddd; }
    h1 { font-weight:normal; margin-bottom:.4em; }
    h1 span { font-size:60%; color:#666; font-weight:normal; }
    table { border:none; border-collapse: collapse; width:100%; }
    td, th { vertical-align:top; padding:2px 3px; }
    th { width:12em; text-align:right; color:#666; padding-right:.5em; }
    #info { background:#f6f6f6; }
    #info ol { margin: 0.5em 4em; }
    #info ol li { font-family: monospace; }
    #summary { background: #ffc; }
    #explanation { background:#eee; border-bottom: 0px none; }
  </style>
</head>

how can i fix this? or this is not where i should be looking . 

 


On Friday, 14 November 2008 17:52:15 UTC-8, Malcolm Tredinnick wrote:

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

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2d2f6720-9e2e-4a3c-afa0-2fd3e9e76c43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment