From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
Error 404--Not Found
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
Many IT managers face a dilemma when attempting to consolidate identity information from a directory service with business data from one or more relational database management systems (DBMS) and present it in a coherent manner to employees, partners, vendors and customers. You'd like the information to be in one data store for ease of use and enhanced security, but which one - the directory or the database?
Radiant Logic, an Internet infrastructure software company, says both. The company has delivered RadiantOne, a "virtual directory server" that combines relational DBMS data with directory service identity through the use of SQL-like connectors dubbed Information Resource Locators (IRL). An IRL is simply a pointer. It's stored in the directory and points to the location of a piece of data (a field, row or calculated value) in a relational DBMS.
No data synchronization is necessary; the relational DBMS value is retrieved when needed by any directory viewer application. This way, each data store can be optimized for what it does best: the directory for browsing, the database for transaction processing. Yet business data can be presented when and where it's needed, through the browsing facilities of any Lightweight Directory Access Protocol (LDAP) viewer using enhanced security options - access control lists for each object and attribute, for example - only available with a robust directory service.
RadiantOne is also flexible in data presentation. Depending on the query it receives, RadiantOne can render the data as XML-, LDAP- or SQL-formatted information when returned to the browsing application. This makes the virtual directory server an ideal engine for furthering e-commerce applications that rely on one or more back-end databases for sales, order, catalog or other data while leveraging the hierarchical structure of the directory for secure, easily implemented browsing. RadiantOne works with LDAP Version 3 directory servers and most major relational database products.
You may not be aware that you need RadiantOne, but once you've implemented it you'll wonder how you ever did without it.
Kearns is a freelance writer and consultant in Austin, Texas. He also authors Network World newsletters on directory services, NetWare and Windows.Related links