Broken Image Link

Discussion in 'HTML' started by mcp6453, Sep 3, 2004.

  1. mcp6453

    mcp6453 Guest

    Can someone here look at the code at http://www.patents.com and tell me
    why the image is not displaying? It is not my site, but I am curious
    about the comment that something in IE is broken.
     
    mcp6453, Sep 3, 2004
    #1
    1. Advertising

  2. mcp6453

    Dave Guest

    Dave, Sep 3, 2004
    #2
    1. Advertising

  3. mcp6453

    Neal Guest

    On Fri, 03 Sep 2004 13:08:22 GMT, mcp6453 <> wrote:

    > Can someone here look at the code at http://www.patents.com and tell me
    > why the image is not displaying?


    Interesting, I'm somehow given a username and password. What's the use of
    that?

    Anyway, it's done in Hotmetal which is really awful IMO. I'm surprised it
    works in any browser. It's not an HTML 4 document, it's something else.

    But as the image is included with Javascript, you need a Javascript
    newsgroup to solve the image issue.

    Followups to comp.lang.javascript

    > It is not my site, but I am curious
    > about the comment that something in IE is broken.


    I think it's a bunch of bull. This site is so incompetent, I wouldn't
    trust them if they told me it was dark at night.
     
    Neal, Sep 3, 2004
    #3
  4. mcp6453

    mcp6453 Guest

    Dave wrote:
    >
    > In article <>, says...
    > > Can someone here look at the code at http://www.patents.com and tell me
    > > why the image is not displaying? It is not my site, but I am curious
    > > about the comment that something in IE is broken.
    > >

    > this is a valid link ?
    >
    >

    http://demo:/axis-cgi/jpg/image.cgi?resolution=
    320x240&dummy=1094217750383


    I just pasted it into IE and it opened an image for me.
     
    mcp6453, Sep 3, 2004
    #4
  5. mcp6453

    sma1king Guest

    "mcp6453" <> wrote in message
    news:...
    > Can someone here look at the code at http://www.patents.com and tell me
    > why the image is not displaying? It is not my site, but I am curious
    > about the comment that something in IE is broken.


    They put their names on this????
     
    sma1king, Sep 3, 2004
    #5
  6. mcp6453

    Arne Guest

    mcp6453 skrev 2004-09-03 15:34:

    > Dave wrote:
    >>
    >> In article <>, says...
    >> > Can someone here look at the code at http://www.patents.com and tell me
    >> > why the image is not displaying? It is not my site, but I am curious
    >> > about the comment that something in IE is broken.
    >> >

    >> this is a valid link ?
    >>
    >>

    > http://demo:/axis-cgi/jpg/image.cgi?resolution=
    > 320x240&dummy=1094217750383
    >
    >
    > I just pasted it into IE and it opened an image for me.


    It's just an ordinary Axis webcam camera view, reloaded every 30 sec.
    The link above can be shortened to
    http://demo:/axis-cgi/jpg/image.cgi?
    since the rest don't affect the link.

    Resolution=320x240 is the image size in pixels, but not really needed
    there, because 320x240 is the default size for the camera to show the
    images. The rest (&dummy=1094217750383) I don't really know what it's for.

    Why is'nt it shown in IE? That's because there is no OBJECT ID code in
    the Javascript, that I belive is needed to call the ActiveX in IE.
    IE can't show this kind of webcams without ActiveX, and if you disable
    that in IE you can't view the cameras even if the code is there. Other
    browsers don't need the OBJECT ID, just a link to the camera outside of
    the OBJECT ID coding.

    I have a similar webcam on http://w1.978.telia.com/~u97802964/webcam.html
    Look at the source, if you like to how it's done.

    Followups to comp.lang.javascript

    --
    /Arne
     
    Arne, Sep 3, 2004
    #6
  7. Arne <> wrote:

    > The link above can be shortened to
    > http://demo:/axis-cgi/jpg/image.cgi?
    > since the rest don't affect the link.


    Huh? Of course it affects - it's data to a CGI script.

    The key issue here might be the fact that the URL is nonstandard (no
    username:password part is allowed in http URLs by the specs) and the fact
    that this year, IE dropped support to the construct, due to security
    reasons. Some people might have an old version of IE that hasn't got this
    patch installed, so maybe the link "works" for them.

    > Followups to comp.lang.javascript


    No, you didn't set any f'ups. Now set to alt.html.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Sep 3, 2004
    #7
  8. mcp6453

    Arne Guest

    Jukka K. Korpela skrev 2004-09-03 18:20:

    > Arne <> wrote:
    >
    >> The link above can be shortened to
    >> http://demo:/axis-cgi/jpg/image.cgi?
    >> since the rest don't affect the link.

    >
    > Huh? Of course it affects - it's data to a CGI script.


    How then? It works just fine for me to get the image up with that
    shorter link, and its not any different if I add the rest. That is in
    Mozilla ofcause, sorry I forget to mention that. :)

    > The key issue here might be the fact that the URL is nonstandard (no
    > username:password part is allowed in http URLs by the specs) and the fact
    > that this year, IE dropped support to the construct, due to security
    > reasons. Some people might have an old version of IE that hasn't got this
    > patch installed, so maybe the link "works" for them.


    The password thingy is on http://west.patents.com/ if you have IE (pw is
    "demo"). After that a different page (where the image is shown even for
    IE) than with http://www.patents.com/

    With Mozilla I get right on to the page, no need for password. Very
    strange thing, but only a demo of some kind that I don't understad the
    purpose of. :)

    >> Followups to comp.lang.javascript

    >
    > No, you didn't set any f'ups. Now set to alt.html.


    Sorry, it went wrong :)

    --
    /Arne
     
    Arne, Sep 3, 2004
    #8
  9. mcp6453

    Grant Wagner Guest

    "Jukka K. Korpela" wrote:

    > Arne <> wrote:
    >
    > The key issue here might be the fact that the URL is nonstandard (no
    > username:password part is allowed in http URLs by the specs) and the fact
    > that this year, IE dropped support to the construct, due to security
    > reasons.


    According to <url: http://www.ietf.org/rfc/rfc1738.txt /> section 3.1:

    <quote>
    While the syntax for the rest of the URL may vary depending on the particular
    scheme selected, URL schemes that involve the direct use of an IP-based
    protocol to a specified host on the Internet use a common syntax for the
    scheme-specific data:

    //<user>:<password>@<host>:<port>/<url-path>

    Some or all of the parts "<user>:<password>@", ":<password>", ":<port>", and
    "/<url-path>" may be excluded.
    </quote>

    And according to <url: http://www.ietf.org/rfc/rfc2396.txt /> section 3.2.2:

    <quote>
    URL schemes that involve the direct use of an IP-based protocol to a
    specified server on the Internet use a common syntax for the server component
    of the URI's scheme-specific data:

    <userinfo>@<host>:<port>
    </quote>

    and later:

    <quote>
    Some URL schemes use the format "user:password" in the userinfo field. This
    practice is NOT RECOMMENDED, because the passing of authentication
    information in clear text (such as URI) has proven to be a security risk in
    almost every case where it has been used.
    </quote>

    So. While it is clearly not recommended to use http://user:password@host, it
    appears that, contrary to what you stated, the construct is part of the
    specification.

    --
    Grant Wagner <>
    comp.lang.javascript FAQ - http://jibbering.com/faq
     
    Grant Wagner, Sep 3, 2004
    #9
  10. Grant Wagner <> wrote:

    > According to <url: http://www.ietf.org/rfc/rfc1738.txt /> section 3.1:


    Read clause 3.4, which defines the specific syntax of http URLs and
    trumps any generic descriptions (as the text you quoted implies) and is,
    in fact, still in force, unlike the generic syntax described in RFC 1738
    (not that it would matter, since RFC 2396 also specifies
    username:password as part of the generic syntax, _without_ implying that
    it would be allowed in all URL types - but quoting the generic part of
    RFC 1738 is a sure sign of not being quite up to date with RFC URLs).

    Followups set again. Please explain why you override Followup-To if you
    feel compelled to do so.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Sep 3, 2004
    #10
  11. mcp6453

    Bill Logan Guest

    "Dave" <> wrote in message
    news:...
    > In article <>, says...
    > > Can someone here look at the code at http://www.patents.com and tell me
    > > why the image is not displaying? It is not my site, but I am curious
    > > about the comment that something in IE is broken.
    > >

    > this is a valid link ?
    >
    > http://demo:/axis-cgi/jpg/image.cgi?resolution=
    > 320x240&dummy=1094217750383


    What is not valid? It works!
     
    Bill Logan, Sep 3, 2004
    #11
  12. mcp6453

    Bill Logan Guest

    "Arne" <> wrote in message
    news:ZP%Zc.102459$...
    > mcp6453 skrev 2004-09-03 15:34:
    >
    > > Dave wrote:
    > >>
    > >> In article <>,

    says...
    > >> > Can someone here look at the code at http://www.patents.com and tell

    me
    > >> > why the image is not displaying? It is not my site, but I am curious
    > >> > about the comment that something in IE is broken.
    > >> >
    > >> this is a valid link ?
    > >>
    > >>

    > > http://demo:/axis-cgi/jpg/image.cgi?resolution=
    > > 320x240&dummy=1094217750383
    > >
    > >
    > > I just pasted it into IE and it opened an image for me.

    >
    > It's just an ordinary Axis webcam camera view, reloaded every 30 sec.
    > The link above can be shortened to
    > http://demo:/axis-cgi/jpg/image.cgi?
    > since the rest don't affect the link.

    Not in your browser perhaps, but is required for other browsers.


    > Resolution=320x240 is the image size in pixels, but not really needed
    > there, because 320x240 is the default size for the camera to show the
    > images. The rest (&dummy=1094217750383) I don't really know what it's

    for.

    Forces a bypass of browser cache!

    > Why is'nt it shown in IE? That's because there is no OBJECT ID code in
    > the Javascript, that I belive is needed to call the ActiveX in IE.

    Funny, I have no active x but it works for me in IE.

    > IE can't show this kind of webcams without ActiveX, and if you disable
    > that in IE you can't view the cameras even if the code is there. Other
    > browsers don't need the OBJECT ID, just a link to the camera outside of
    > the OBJECT ID coding.

    Why does it need that? It is not using the video, it is using stills!


    > I have a similar webcam on http://w1.978.telia.com/~u97802964/webcam.html
    > Look at the source, if you like to how it's done.


    Perhaps you should have looked at their code? While yours needs the active
    x because it is delivering video, theirs does not because it is delivering
    a sequence of stills (jpg) images and the JS is simply reloading.
     
    Bill Logan, Sep 3, 2004
    #12
  13. mcp6453

    Bill Logan Guest

    "Jukka K. Korpela" <> wrote in message
    news:Xns9559C4D78F142jkorpelacstutfi@193.229.0.31...
    > Arne <> wrote:
    >
    > > The link above can be shortened to
    > > http://demo:/axis-cgi/jpg/image.cgi?
    > > since the rest don't affect the link.

    >
    > Huh? Of course it affects - it's data to a CGI script.


    Huh, not data to the cgi - it forces a bypass of the browser cache

    > The key issue here might be the fact that the URL is nonstandard (no
    > username:password part is allowed in http URLs by the specs) and the fact
    > that this year, IE dropped support to the construct, due to security

    Huh, when did that happen and please let me know (URL) Many of my sites
    send usernames passwords in the url (encypted of course) and it is needed
    in command line hhtp requests so please, do tell???

    > reasons. Some people might have an old version of IE that hasn't got this
    > patch installed, so maybe the link "works" for them.

    If you are talking about the security patch? Worse thing is to install it.
    (the patch) causes more problems than it solves. (IMHO)
     
    Bill Logan, Sep 3, 2004
    #13
  14. "Bill Logan" <> wrote:

    >> > The link above can be shortened to
    >> > http://demo:/axis-cgi/jpg/image.cgi? since
    >> > the rest don't affect the link.

    >>
    >> Huh? Of course it affects - it's data to a CGI script.

    >
    > Huh, not data to the cgi - it forces a bypass of the browser cache


    You don't know what CGI is, do you? Of course it _could_ be something
    else (there is no magic in the two occurrences of the string "cgi", but
    the indications are pretty clear in practice). And it does not force a
    browser. It is data that the browser sends to the server. Whether the
    server uses it is up to the server.

    >> The key issue here might be the fact that the URL is nonstandard (no
    >> username:password part is allowed in http URLs by the specs) and the
    >> fact that this year, IE dropped support to the construct, due to
    >> security

    > Huh, when did that happen and please let me know (URL)


    Try googling with http+url+password, and probably the second hit points
    to Microsoft's information on the matter.

    > If you are talking about the security patch? Worse thing is to
    > install it. (the patch) causes more problems than it solves. (IMHO)


    So you think you will rely, in your authoring, on all IE users _not_ to
    install security patches (which stop IE from doing something it shouldn't
    have been doing in the first place)?

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Sep 3, 2004
    #14
  15. mcp6453

    Bill Logan Guest

    "Jukka K. Korpela" <> wrote in message
    news:Xns9559E97679F36jkorpelacstutfi@193.229.0.31...
    > "Bill Logan" <> wrote:
    >
    > >> > The link above can be shortened to
    > >> > http://demo:/axis-cgi/jpg/image.cgi? since
    > >> > the rest don't affect the link.
    > >>
    > >> Huh? Of course it affects - it's data to a CGI script.

    > >
    > > Huh, not data to the cgi - it forces a bypass of the browser cache

    >
    > You don't know what CGI is, do you? Of course it _could_ be something
    > else (there is no magic in the two occurrences of the string "cgi", but
    > the indications are pretty clear in practice). And it does not force a
    > browser. It is data that the browser sends to the server. Whether the
    > server uses it is up to the server.

    That tells me you dont know much about cgi. Not all 'data' returned to the
    server in the request is always used by the server script. In this case the
    dummy variable is used to force the browser to (reload) the new image.
    (otherwise it may thing the image is the same as the one in its cache and
    will simply load that. - defeating the purpose. So yes, the dummy is there
    to 'froce' the browser to reload the same (but different) image.



    >
    > >> The key issue here might be the fact that the URL is nonstandard (no
    > >> username:password part is allowed in http URLs by the specs) and the
    > >> fact that this year, IE dropped support to the construct, due to
    > >> security

    > > Huh, when did that happen and please let me know (URL)

    >
    > Try googling with http+url+password, and probably the second hit points
    > to Microsoft's information on the matter.

    LOL, I didnt ask what the RFCs say. I asked when did it become non standard
    (practice)? The specs do not always determin what becomes standard
    practice - although often they do.

    However, in the case of RFC1738 there is some variation between
    interpretations of the RFC. Microsoft, as you point out has interpreted it
    from the http section (3.3) exclusively. Yet, section 3.1 allows for the
    username password - in IP based schemes. While IE has dropped the support,
    and has included a security fix for browsers that still have it, there are
    also published work arounds that allow one to bypass this restriction
    imposed by MS.

    Additionally, using a username password in the url this way IS standard
    practice when requesting http via the command line. EG wget has good
    documentation on using this method.

    > > If you are talking about the security patch? Worse thing is to
    > > install it. (the patch) causes more problems than it solves. (IMHO)

    >
    > So you think you will rely, in your authoring, on all IE users _not_ to
    > install security patches (which stop IE from doing something it shouldn't
    > have been doing in the first place)?


    Of course not. Passing the username password in the URL is useful for
    particular cases, not all cases in general. For situations where it is
    warrented, the visitor would be aware of what is required and select their
    UA accordingly. I wouldnt use IE to request http from the command line (do
    not know if that can even be done)
     
    Bill Logan, Sep 3, 2004
    #15
  16. "Bill Logan" <> wrote:

    > That tells me you dont know much about cgi.


    Really? Your evidence of my misunderstanding is eloquent in its brevity
    (that's a polite word for "nonexistence"). That is, you seem to just
    babbling, with no evidence whatsoever.

    > So yes, the dummy is there to 'froce'


    Oh yeah.

    >> Try googling with http+url+password, and probably the second hit
    >> points to Microsoft's information on the matter.

    > LOL, I didnt ask what the RFCs say.


    You obviously should have. Moreover,

    > I asked when did it become non standard (practice)?


    It always was nonstandard. Your calling nonstandard behavior does not
    make it standard.

    Besides, the way I described, you could easily have found out when the
    leading manufacturer stopped supporting the nonstandard method you still
    seem to be relying on.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Sep 4, 2004
    #16
  17. "Bill Logan" <> wrote:

    > That tells me you dont know much about cgi.


    Really? Your evidence of my misunderstanding is eloquent in its brevity
    (that's a polite word for "nonexistence"). That is, you seem to just
    babbling, with no evidence whatsoever.

    > So yes, the dummy is there to 'froce'


    Oh yeah.

    >> Try googling with http+url+password, and probably the second hit
    >> points to Microsoft's information on the matter.

    > LOL, I didnt ask what the RFCs say.


    You obviously should have. Moreover,

    > I asked when did it become non standard (practice)?


    It always was nonstandard. Your calling nonstandard behavior does not
    make it standard.

    Besides, the way I described, you could easily have found out when the
    leading manufacturer stopped supporting the nonstandard method you still
    seem to be relying on.

    > However, in the case of RFC1738 there is some variation between
    > interpretations of the RFC.


    Only the usual variation between people who understand what it says and
    people who don't, in this matter.

    > Microsoft, as you point out has interpreted it
    > from the http section (3.3) exclusively.


    Microsoft dropped support for the nonstandard feature for security
    reasons. It has little to do with interpretations of RFCs.

    > Yet, section 3.1 allows for the
    > username password - in IP based schemes.


    Have you actually read RFC 1738 yet? Don't bother, anyway, its generic
    definitions have been superseded, as I explained. And section 3.1 never
    allowed anything, it only described a general pattern and fairly
    explicitly said that it does not say what the specific URL formats are.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Sep 4, 2004
    #17
  18. mcp6453

    Bill Logan Guest

    "Jukka K. Korpela" <> wrote in message
    news:Xns955A181D8DC0Djkorpelacstutfi@193.229.0.31...
    > "Bill Logan" <> wrote:
    >
    > > That tells me you dont know much about cgi.

    >
    > Really? Your evidence of my misunderstanding is eloquent in its brevity
    > (that's a polite word for "nonexistence"). That is, you seem to just
    > babbling, with no evidence whatsoever.


    You want evidence? OK - you said I had no understanding of cgi but offered
    no proof or examples. The when another poster (rightly said) parts of the
    link did not effect the url you responded with they did effect as they were
    (needed) data to a cgi script. That shows your lack of knowledge for
    starters. First of all, the 'resolution' and 'dummy' bits are not data!
    They are in fact variables and their existance or non existance have no
    effect on that particulr cgi! They are (optionally) there as variables the
    cgi can pass directly back to the browser for use by the browser. If they
    are not there the image simply loads as the default.
    If they are there they tell the browser the dimision of this image and also
    to reload the image and not to use the browsers cache.
    Further evidence of your lack of understanding - the fact you didnt even
    bother to check to see how that script works and understand its method!

    I suspect your understanding / knowledge of cgi is on a par with your
    knowledge / understanding of web page authoring - (as displayed in your
    sig?)

    Well my friend, have news for you. Your pages do not validate. You are
    'still' useing a transitional - (incomplete?) doc type and tables for
    layout.

    You discuss the use of css with the heading why css is harmful. Even I, as
    a novice in that area can see glaring errors in your description of style
    sheets and what they are about. Moreover, as an opponant of particular use
    of style sheets I find your arguments against give little credence to the
    idea.

    Your whole site about assisting people with authoring web pages is a good
    example of how not to. Perhaps that was your intention?
     
    Bill Logan, Sep 4, 2004
    #18
  19. In article <41394eda$>,
    "Bill Logan" <> wrote:

    [Someone somewhere in this thread, god help us, posted the disputed URL:
    http://demo:/axis-cgi/jpg/image.cgi?resolution=
    320x240&dummy=1094217750383 ]

    > First of all, the 'resolution' and 'dummy' bits are not data!
    > They are in fact variables and their existance or non existance have no
    > effect on that particulr cgi! They are (optionally) there as variables the
    > cgi can pass directly back to the browser for use by the browser.


    What exactly do you mean by "pass directly back to the browser"?

    > If they are not there the image simply loads as the default. If they are there
    > they tell the browser the dimision of this image...


    Whoa. Okay, after having read this over five times and stared at the URL
    for a while, I think I understand what you're trying to say, but you are
    saying it in a way which at best invites confusion and which more likely
    will get you immediately dismissed by anyone with a clue about browsers,
    webservers and URLs work.

    First, no browser parses a URL like the above and determines that the
    image (or whatever image.cgi induces the webserver to spew back at the
    browser) is 320x240 &units; in size. Browsers might parse URL fragments
    -- those little suffixes beginning with '#' - but they don't parse the
    query string. If you disagree, please name a browser which does parse
    the "dimision" directly from the query string above.

    But I don't think that's what you're trying to say.

    I suspect what you're trying to say is that the webserver uses this
    information to determine the dimensions (which isn't the same as the
    resolution BTW, but I digress) of the image to be returned to browser.
    If that's what you're trying to say, you could well be right, but your
    expression of that concept is severely lacking in clarity.

    > and also to reload the image and not to use the browsers cache.


    Again, browsers do not parse query strings and take action: servers do.
    If you're trying to say that browsers *can* cache documents returned by
    GET-type requests (which they can though they don't _have_ to), that the
    cache is often implemented by hashing the URL, and that using a URL with
    a unique 'dummy' parameter in the query string will likely cause the
    browser to submit the GET request to the server rather than fall back on
    its (now broken) cache for what is otherwise the same image ... again,
    you're probably right, but you're not explaining it well.

    Browsers do not parse query strings, so the query string can't "tell"
    the browser to *do* anything. Stating that it can will only cause
    confusion.

    --
    Joel.

    http://www.cv6.org/
    "May she also say with just pride:
    I have done the State some service."
     
    Joel Shepherd, Sep 4, 2004
    #19
  20. mcp6453

    Bill Logan Guest

    "Joel Shepherd" <> wrote in message
    news:...
    > In article <41394eda$>,
    > "Bill Logan" <> wrote:
    >
    > [Someone somewhere in this thread, god help us, posted the disputed URL:
    > http://demo:/axis-cgi/jpg/image.cgi?resolution=
    > 320x240&dummy=1094217750383 ]
    >
    > > First of all, the 'resolution' and 'dummy' bits are not data!
    > > They are in fact variables and their existance or non existance have no
    > > effect on that particulr cgi! They are (optionally) there as variables

    the
    > > cgi can pass directly back to the browser for use by the browser.

    >
    > What exactly do you mean by "pass directly back to the browser"?

    OK typed in a hurry, should have said for use / information at the browser
    end. Mostely much like comments in html.

    > > If they are not there the image simply loads as the default. If they

    are there
    > > they tell the browser the dimision of this image...

    >
    > Whoa. Okay, after having read this over five times and stared at the URL
    > for a while, I think I understand what you're trying to say, but you are
    > saying it in a way which at best invites confusion and which more likely
    > will get you immediately dismissed by anyone with a clue about browsers,
    > webservers and URLs work.
    >
    > First, no browser parses a URL like the above and determines that the
    > image (or whatever image.cgi induces the webserver to spew back at the
    > browser) is 320x240 &units; in size. Browsers might parse URL fragments
    > -- those little suffixes beginning with '#' - but they don't parse the
    > query string. If you disagree, please name a browser which does parse
    > the "dimision" directly from the query string above.


    I did not say the browser parses anything.
    >
    > But I don't think that's what you're trying to say.
    >
    > I suspect what you're trying to say is that the webserver uses this
    > information to determine the dimensions (which isn't the same as the
    > resolution BTW, but I digress) of the image to be returned to browser.
    > If that's what you're trying to say, you could well be right, but your
    > expression of that concept is severely lacking in clarity.

    No I did not. The server in this case does not determin the dimensions.
    They are loaded into the vid camera that produces the image. (by the
    actions of the cgi)


    >
    > > and also to reload the image and not to use the browsers cache.

    >
    > Again, browsers do not parse query strings and take action: servers do.
    > If you're trying to say that browsers *can* cache documents returned by
    > GET-type requests (which they can though they don't _have_ to), that the
    > cache is often implemented by hashing the URL, and that using a URL with
    > a unique 'dummy' parameter in the query string will likely cause the
    > browser to submit the GET request to the server rather than fall back on
    > its (now broken) cache for what is otherwise the same image ... again,
    > you're probably right, but you're not explaining it well.
    >
    > Browsers do not parse query strings, so the query string can't "tell"
    > the browser to *do* anything. Stating that it can will only cause
    > confusion.

    I think you are confused! I never said the browser parsed anyhting. I said
    the server sends the information back to the browser so the browser will
    'reload' the image with the provided dimensions.
     
    Bill Logan, Sep 4, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest
    Replies:
    1
    Views:
    430
    Michael Pearson
    Oct 30, 2003
  2. Kevin Spencer

    Re: Link Link Link DANGER WILL ROBINSON!!!

    Kevin Spencer, May 17, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    956
    Kevin Spencer
    May 17, 2005
  3. Steven D'Aprano

    Why are "broken iterators" broken?

    Steven D'Aprano, Sep 21, 2008, in forum: Python
    Replies:
    8
    Views:
    696
  4. Cameron Simpson

    Re: Why are "broken iterators" broken?

    Cameron Simpson, Sep 22, 2008, in forum: Python
    Replies:
    0
    Views:
    617
    Cameron Simpson
    Sep 22, 2008
  5. Fredrik Lundh

    Re: Why are "broken iterators" broken?

    Fredrik Lundh, Sep 22, 2008, in forum: Python
    Replies:
    0
    Views:
    629
    Fredrik Lundh
    Sep 22, 2008
Loading...

Share This Page