Hmm, okay, I was wrong, the fragment is sent to the server. As I expect
you knew before asking, heh. Weird. Since the HTTP spec doesn't seem to
allow for it.
Interestingly, while curl as a user-agent sends the fragment, wget does
NOT. I suspect that many programming libraries used for HTTP get
requests won't send it either, as I don't think I'm the only one under
the impression that it's not supposed to be sent to the server. Let's
see if ruby open-uri does... ruby open-uri does NOT,
open("http://something/index#fragment") in ruby results in simply
"/index" in the apache logs, NOT "index#fragment".
I'm not sure it's not _curl_ that's misbehaving, rather than those other
things!
This definitely makes things even MORE confusing to me. I don't like
those fragment identifiers.
Jonathan
Ross Singer wrote:
> On Thu, Nov 12, 2009 at 10:13 AM, Jonathan Rochkind <rochkind_at_jhu.edu> wrote:
>
>
>> Huh, I don't think this is true. I thought it was part of HTTP in general,
>> regardless of content-type, that the user-agent will never send the
>> "fragment identifier" (aka the "hash part") to the server. So the
>> disposition of a request can't possibly be determiend by the server based on
>> the fragment identifier, whether it's text/html or application/xml or
>> anything else. It's not a special case for HTML, it's general for anything
>> HTTP.
>>
>
> Jonathan, if you have access to the commandline "curl", try opening a
>
> tail -f /path/to/your/apache/access/log
>
> in one terminal and then in another terminal
>
> curl "http://some.url.that.the.above.log.will.see/index.html#somecrazyfragment"
>
> and tell me what url appears in your log.
>
> -Ross.
>
>
Received on Thu Nov 12 2009 - 10:29:52 EST