Broken Image Link

[mcp6453]

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.

 

[Dave]

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:[email protected]/axis-cgi/jpg/image.cgi?resolution=
320x240&dummy=1094217750383

 

[Neal]

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.

 

[mcp6453]

this is a valid link ?

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


I just pasted it into IE and it opened an image for me.

 

[sma1king]

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????

 

[Arne]

mcp6453 skrev 2004-09-03 15:34:

http://demo:[email protected]/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:[email protected]/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

 

[Jukka K. Korpela]

The link above can be shortened to
http://demo:[email protected]/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
usernameassword 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.

 

[Arne]

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

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
usernameassword 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.

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

Sorry, it went wrong

 

[Grant Wagner]

The key issue here might be the fact that the URL is nonstandard (no
usernameassword 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 "userassword" 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.

 

[Jukka K. Korpela]

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
usernameassword 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.

 

[Bill Logan]

this is a valid link ?

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

What is not valid? It works!

 

[Bill Logan]

mcp6453 skrev 2004-09-03 15:34:

It's just an ordinary Axis webcam camera view, reloaded every 30 sec.
The link above can be shortened to
http://demo:[email protected]/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]

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
usernameassword 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)

 

[Jukka K. Korpela]

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.

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)?

 

[Bill Logan]

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.

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.

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)

 

[Jukka K. Korpela]

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.

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.

 

[Jukka K. Korpela]

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.

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.

 

[Bill Logan]

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?

 

[Joel Shepherd]

[Someone somewhere in this thread, god help us, posted the disputed URL:
http://demo:[email protected]/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."

 

[Bill Logan]

[Someone somewhere in this thread, god help us, posted the disputed URL:
http://demo:[email protected]/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.

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)

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.