Jump to content

Combining Hashes and Query Strings in an HTTP Request


iwato

Recommended Posts

BACKGROUND:  I was recently introduced to the idea of using a hash as a means to transfer information in lieu of a query string in an HTTP request.  Having thought that I understood the idea I was then introduced to the following query string:

https://www.example.com/index.php
	?module=CoreHome
	&action=index
	&idSite=1
	&period=day
	&date=yesterday
	#?idSite=1
		&period=day
		&date=yesterday
		&category=Dashboard_Dashboard
		&subcategory=1

I do not understand the user the expression  ... #? ...   From the point of view of parsing an HTTP request are the following two hash expressions treated the same?

1) https://www.example.com/index.php#blahblahblah

2) https://www.example.com/index.php?some_query_string#blahblahblah

Accept for the order of parsing do items 2) and 3) achieve the same task?

3) https://www.example.com/index.php#blahblahblah?some_query_string

Roddy

ps:  In which forum to questions about HTTP requests belong anyway?

Link to comment
Share on other sites

Nothing that follows the hash ever gets sent to the server, not even if it looks like a query string. The hash is always the last part of the URL.

In item 1), the server loads the index page. In item 2) the server loads the index page with access to the contents of the query string. Item 3) is identical to item 1), no additional information is sent to the server because all of the remaining data is in the hash, which is only used by the browser. 

HTTP is very commonly used in web services, so it's not out of place to ask about it on the Web Services forum, but most of your usage of HTTP pertains to HTML and PHP, so either of those forums would work as well. 

  • Like 1
Link to comment
Share on other sites

OK. But what happens to the hash in Item 2?

Is it a part of the query string?  Or, does it refer to an anchor on the page to where the query string is sent?  Or, is it something else altogether?

Roddy

Link to comment
Share on other sites

The URL in example 3 is not valid.  In the specification for URLs, the optional querystring precedes the optional fragment/anchor.  Here's the actual RFC:

https://www.ietf.org/rfc/rfc1738.txt

Quote

OK. But what happens to the hash in Item 2?

Is it a part of the query string?

No.

 

Or, does it refer to an anchor on the page to where the query string is sent?

It's supposed to, that was the original purpose.  When people realized they could set that value without the page refreshing and use it for bookmarking or other clever ways inside their Javascript applications, they extended the usage of it.

  • Like 1
Link to comment
Share on other sites

JSG:  OK. Item 3 is invalid.  As you have just stated, however, all that is invalid is not dysfunctional.  How is one to interpret the #? in

https://www.example.com/index.php
	?module=CoreHome
	&action=index
	&idSite=1
	&period=day
	&date=yesterday
	#?idSite=1
		&period=day
		&date=yesterday
		&category=Dashboard_Dashboard
		&subcategory=1

Can it function as a  piggy-back ride on the original query that is parsed on arrival and added as a query string to a different URL?

1) https://www.example.com/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday

2) Parse the hash and append to otherpage.html

3) ./otherpage.html?idSite=1&period=day&date=yesterday&category=Dashboard_Dashboard &subcategory=1

Roddy

Edited by iwato
Link to comment
Share on other sites

How is one to interpret the #? in

There's not a rule that says the hash value cannot contain or start with a question mark, as far as I'm aware.  The question mark has no special meaning in that location.  I don't know why they used it, maybe as a delimiter or maybe as a way to fool some faulty URL checker into considering that a valid URL (which it is).

Can it function as a  piggy-back ride on the original query that is parsed on arrival and added as a query string to a different URL?

I'm not sure what that means.  I don't even know if that part of the URL is even sent by the browser to the server.  You could test that though, if you print the entire $_SERVER array you'll see what the browser sent to the server and what PHP did with it.

  • Like 1
Link to comment
Share on other sites

OK. I just reread what Ingolme wrote and would like to change the question

Can it serve to send to HTTP Requests from the same page.

1) https://www.example.com/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday

2) Parse the hash on the same page on which the link resides and use Javascript to append it to another URL

3) https://www.otherURL.com/index.php??idSite=1&period=day&date=yesterday&category=Dashboard_Dashboard &subcategory=1

Link to comment
Share on other sites

To answer your question, Javascript can do pretty much anything. It can read the hash of the URL by accessing the location.hash property. It can construct a URL using string manipulation and then redirect the browser to another page using location.assign().

I recommend not doing any of that. On ordinary websites, it's not a good idea to use the hash for any other purpose other than what it was designed for. I don't know why you want to use the hash as a data transfer mechanism, but almost certainly there is a better way. You should clearly define your end goal before deciding which technologies to use to achieve it.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...