@jar346's document, meant to elicit a clearer response from Tennison et al. about httpRange-14-related stuff. Gah.

REST-access library for Java, in the style of that Python library I can never remember the name of.

"Usage: http://httpcats.herokuapp.com/[http_status_code]"

The RECOP distribution site.

Now I just need to figure out how to fix the FTP proxy issue.

<banging head against wall...>

"htty is a console application for interacting with HTTP servers. It’s something of a cross between curl and the Lynx browser." -- Yessss....

It's hard to know what to think, here. What do companies like this expect, when they ask people to post personal (and potentially valuable) details about themselves in a common forum? I also object to the use of the word "scraper" here, very similar to the way in which the word "hacker" was co-opted by the popular press and made into a dirty word, 15+ years ago.

Running a proxy using a servlet within Jetty.

This would be a great way to visualize other protocols.

Jonathan's revised set of ideas about HTTP and Linked Data, posted on the W3C blog.

Thinking about APIs for HTTP interaction libraries.

I already saved a link to this before, but I'm re-saving it to emphasize a different part: "I’d like us to be clear about first principles: when you’re given an RDF graph, and you’re looking for more information that might be useful, you should dereference the predicate IRIs to learn about what kinds of inference you’re entitled to do. And then, given resources and suitable reasoners, you should do it. That is, the use of particular IRIs as predicates implies certain things, as defined by the IRI’s owner. The graph is invoking certain logics by using those IRIs. (Of course you can always infer things that were not implied, but as among humans, those “inferences” are really just guesses you are making. They have quite a different status from true implications.)"

Jonathan's revised draft. The story here is that HTTP and "semantic web" don't mix, if you require that http: URIs *only* be interpreted using the protocol. (Or that their meaning be compatible with the results of protocol-compliant interactions.) The final situation here is unclear.

"The TAG's httpRange-14 decision casts uncertainty on location/designation practice by advising for or against the use of GET/200 depending on what the URI names. At the same time it (a) fails to explain which things are restricted, (b) fails to prove the existence of the claimed the ambiguity (between a thing and a web page about it), (c) fails to solve the ambiguity when the thing itself is a "information resource". It appears that the intent is that a GET should retrieve something that is "like" the resource, yet the "like" relationship isn't specified adequately to explain the use of 200 responses with entities defined by the various metadata ontologies." -- Jonathan's extended notes. To think about.

The finding in question ("HttpRange-14"). Source of so much controversy.

"RDF statements are assertions about the world. But to understand what a statement means, one has to know what the URIs refer to. One has to know what they name. Despite the centrality of URIs in the RDF data model, the RDF specifications have nothing to say about how a URI actually receives its meaning. This needs fixing. It is possible to get a coherent picture of the process by referring to a number of other documents, in particular the httpRange-14 TAG Finding..." -- Cyganiak is deeply confused, although this is not wholly his own fault.

The origin of the REST-ful design/architecture in web-apps.

"Contrary to news reports that YouTube removed the violent video, the site simply put it behind an age-restricted click-through. That renders the video impossible to find unless you already know the URL." -- In other words, this renders the video incredibly easy to find. I don't understand the point of this article: nothing was "buried." This is the way the web is designed. In fact, Wired's own article, which has the video *embedded under the headline*, puts the lie to its own breathless assertion. Jaysus. "Omission from an arbitrary search index" != "censorship." If at HTTP GET returns 200, you're good to go, BY DEFINITION.

Shouldn't L.M. be off eating something? (http://www.cssquirrel.com/comic/?comic=54) Anyway, JAR and I were literally arguing about this last week (because JAR is on the TAG, and so was complaining that they were addressing this httpRange issue again and that it was causing him to pull his hair out). My theory is that a resource is a thing that has a "content function," which a function with a domain of "time" and a range of "stuff-representable-in-bits." And that the content returned by querying a resource with HTTP is always consistent with everything else you know about the world, and so you can't prove that two resources are the same. Which is a kind of maximalist, anything-goes, the-kids-are-alright kind of approach, and JAR *hates it*. I think.

Pat Hayes to David Booth. "This is confused because of the now venerable confusion, which continuously dogs all these discussions, between "identifying" in the sense of providing a functional Web-mediated connection to something, and referring to an object, aka denoting it. These are (forgive the shout) NOT THE SAME THING. Please don't get them confused."

Quoting -- urllib.quote and urllib.quote_plus was what I wanted.

"The primary focus of the project is to provide a truly embeddable Java based HTTP engine capable of handling enormous loads. Simple provides a truly asynchronous service model, request completion is driven using an internal, transparent, monitoring system. This allows Simple to vastly outperform most popular Java based servers in a multi-tier environment, as it requires only a very limited number of threads to handle very high quantities of concurrent clients." --- I keep thinking that these standalone, Java-based, easily-deployable server-options would be really useful in some kind of distributed graph database project. But I still haven't nailed down the details in my mind... obviously this isn't going to happen while I'm still at school.

In all it's glory/gory detail.

"Although the java.net package provides basic functionality for accessing resources via HTTP, it doesn't provide the full flexibility or functionality needed by many applications. The Jakarta Commons HttpClient component seeks to fill this void by providing an efficient, up-to-date, and feature-rich package implementing the client side of the most recent HTTP standards and recommendations. See the Features page for more details on standards compliance and capabilities."

"A PURL is a Persistent Uniform Resource Locator. Functionally, a PURL is a URL. However, instead of pointing directly to the location of an Internet resource, a PURL points to an intermediate resolution service. The PURL resolution service associates the PURL with the actual URL and returns that URL to the client. The client can then complete the URL transaction in the normal fashion. In Web parlance, this is a standard HTTP redirect." --- All the semantic web guys at W3C here are using the purl redirection service, for setting up their RDF-associated URLs. But OCLC is bad, right?

XMPP and REST and alternatives. Push vs. Poll. Just clearing out the tabs, here...

"Orbited provides a pure JavaScript/HTML socket in the browser." Again, there was some discussion of technology like this over the weekend in WI.

Display headers in real-time (in Firefox)

From the NYT "code" website. SQL queries over http, JSON is returned. A front-end, I think, to Apache.

Using a particular (HTTP 303) response to designate a characteristic of a named resource. Related to the difference between URLs and URIs.