Click here to Skip to main content
15,940,921 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
<img alt="" name="Code_Verify" id="Code_Verify" align="top" src="/ipcast_os/login_auth/display_verify"/>

src is a url, and this url will call a function that it return a image of identification code.
why does the src property is not a path of a image file? thanks in advance.
(i use python and Django)
Updated 15-Apr-13 17:42pm
[no name] 15-Apr-13 20:42pm    
Huh? What? The src property is the path to an image file not to a directory.
daizhan 15-Apr-13 21:57pm    
oh sorry , i have updated it, thank you.
[no name] 15-Apr-13 22:23pm    
I don't think you quite get it. The src property is the path to a file, not a path to a function as if functions have file paths. Even if it was, an "identification code" is not a image.
daizhan 15-Apr-13 23:48pm    
I get a answer in stack maybe can make you understand what i ask.
my english is not good, so i can't describe the question very accurately.
forgive me please.
Sergey Alexandrovich Kryukov 15-Apr-13 22:02pm    

1 solution

These two items are unrelated. The attribute id just uniquely identify any HTML element. It's main use is getting an HTML DOM object by the value of id, by JavaScript:
myElement = document.getElementById(idValue);

Now, about src attribute. Why it is not an image file? Just because it does not have to be. First of all, HTTP servers can use index files and other URI-related techniques which hide the real image file. I will explain only one case, the index file. Actually, that URI can be the virtual directory name (it is incorrect though, please see below). In this directory on the server side, you could have a file recognized as index file by its name pattern, such as index.html, index.htm and the like (the rule for index file name is configurable). So, actually, this could be the image file, but you cannot see it from the URI. Moreover, it does not have to be an image file. If could be the server-side script file which sets the HTTP header of appropriate MIME type, such as "image/jpeg", "image/png".

Here, you should understand that for a Web browser, the file name of file type plays the minimal role. Actual MIME type is sent to the browser in the "content-type" HTML header. Please see:[^],[^],[^].

And finally, I need to explain what's wrong with src="/ipcast_os/login_auth/display_verify". This is a really bad URI, and it can be invalid. Here is the thing: HTTP server should access only those file of the server host's file system which are placed in the directories under the root directory configured for the site. This is a matter of very basic safety. This URI starts from the root directory of the file system; look at the leading '/' symbol. There are no cases where the use of absolute local server's file system path can be useful. Imagine that this file path is valid; it is located under the site's root. But what if you decide to relocate the site? It could be done by the hosting provider, without notifying you; and this would be quite a legitimate action. All your site may be destroyed into inconsistent state. The URIs should be either relative, or based on Internet scheme such as "http://", "ftp://", "https://", etc. In this case, the directory path will be the path relative to the site's root directory.

See also:[^].

Share this answer
daizhan 16-Apr-13 20:44pm    
it depends on the server response with the proper image file, when the request is send to the server. so the src property don't have to be a path to a image file. is it right??
Sergey Alexandrovich Kryukov 16-Apr-13 21:25pm    
Two things: 1) it can be the real image file, but it is not apparent from this URI, 2) it could be script returning image, without image file, on the fly; and the script file name is not apparent from the URI not apparent from the, by the same reasons. You are showing it from the client perspective, where this is all we can see. I explained the ways you can program such behavior...
daizhan 16-Apr-13 21:28pm    
thank you , i have got it.
Sergey Alexandrovich Kryukov 16-Apr-13 23:36pm    
Great; and you are welcome.
Good luck, call again.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900