On Jan 5, 2007, at 4:56 AM, Benjamin Carlyle wrote:

> On Thu, 2007-01-04 at 16:56 -0800, Bill Venners wrote:
>> I did take the canonical URL thing to heart in our new architecture.
>> It may be a bit over-designed but we generate controllers that
>> canonicalize by dropping trailing slashes and even reordering the
>> query parameters. For example:
>> http://www.artima.com/articles?t=java&p=4&o=a
>> http://www.artima.com/articles?p=4&o=a&t=java
> ...
>> http://www.artima.com/articles/?o=a&t=java&p=4
>> All get redirected to:
>> http://www.artima.com/articles?o=a&t=java&p=4
>
> I'm not a fan of redirection for redirection's sake. If it makes for a
> much simpler server implementation so be it, but in general I think it
> is poor manners to ask a client to rephrase a request the server
> understands perfectly well.
>
Well, in my case it makes the server a bit more complicated, not
simpler. By default using Java servlets my server would process all
those URIs the same. I had to add code to canonicalize those URIs
into one URI via redirection. I realized I do one other thing that I
didn't mention. If a URI comes in with a query param at its default
value, I redirect to the same URI minus that query param.

I didn't do this for redirection's sake, but for the purpose of
helping search engines figure out that two different URIs really
refer to the same thing. If the search engine can't figure out that
two different URIs refer to the same thing, and half of the inbound
links use each URI, then Google-like PageRank algos won't put that
page as high in search results as it would have with a canonical URI.
So I invested in some code to canonicalize URIs that my
infrastructure didn't already canonicalize, in the hopes of a pay
back in increased traffic from search engines.

> In all of these cases I would be strongly inclined to process the
> request normally and repond with the relevant content. I would try to
> include a link in the content and/or headers to the bookmark or
> "permalink" url for future reference, but I don't want to clog up the
> network with repetitions of the same request through the redirection
> mechanism. I see redirection primarily as a mechanism to defer to a
> server entity that understands the request properly or to deal with a
> deprecated url.
>
Since all non-canonical URIs are redirected, it should be highly rare
that someone would ever link to one of them. So oddly enough by doing
the redirects, I will actually be preventing people from linking to a
non-canonical URI, in which case the server would never need to do
any redirects.

Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com

> Roy, you wrote:
>> No. Why would I have said "For two resources to be the same, ..." if
>> I thought that changing a URI always resulted in different resources?
>> They might be different resources, the client generally won't be able
>> to figure that out, so the only safe assumption is that they are
>> different resources until stated otherwise by the server.
>
> I worry about the notion of a resource being too airy-fairy. I take a
> fairly simple approach in my conversation. If the urls are
> different we
> are talking about two different resources. It might happen that they
> demarcate the same application state, but client's can't know that. I
> would suggest that even server's don't really know that. A mapping
> from
> URL to representation might be here today but gone after the
> restructure
> tomorrow. One of the aliases might become a redirection next week.
> Severs cannot say with certainty over the long-haul that multiple urls
> map to the same application state. In that context I am very wary of
> language that talks about two resources being the "same", even if the
> might happen to be equivalent for the forseeable future.
>
> I talk about different urls always referring to different
> resources. At
> any particular point in time the url demarcates a specific subset of
> application state, though the server is free to change the mapping
> from
> url to application state over time. Interacting with the resource
> returns, replaces, adds to, destroys, or otherwise operates on the
> demarcated application state by transferring representations of the
> state being communicated. Different representations encode the state
> being communicated into different document types with different
> tradeoffs with respect to fidelity of semantics, document simplicity,
> generality of applicability and other design factors.
>
> Benjamin.
>
>

•  3
  New Members

• Sip protocol
• Protocol analyzer
• Protocol analysis
• Protocol converter
• Protocol