Discussion:
URL redirection question
(too old to reply)
b***@hotmail.com
2017-06-20 14:54:41 UTC
Permalink
I just got a bill on my phone, which said "To pay this bill - go to www.<whatever>" . When I went to the site - it said stuff like "Welcome Mr. John Doe", ie. it *knew from the URL* that it was me! I'm kind of trying to figure out how this was architected - can you guys help? :)

MY brain suggested something like this: whatever was after the "/" in the URL (something like e2gbm853dc or whatever) was an ARGUMENT - when someone types that in to the browser, it redirects to script.php (or whatever) on the server with THAT string as the argument. Which, by querying for that row in a SQL database or something, brings up my name in the company's database..... am I on the right track here?
Barry Margolin
2017-06-20 15:44:07 UTC
Permalink
Post by b***@hotmail.com
I just got a bill on my phone, which said "To pay this bill - go to
www.<whatever>" . When I went to the site - it said stuff like "Welcome Mr.
John Doe", ie. it *knew from the URL* that it was me! I'm kind of trying to
figure out how this was architected - can you guys help? :)
MY brain suggested something like this: whatever was after the "/" in the URL
(something like e2gbm853dc or whatever) was an ARGUMENT - when someone types
that in to the browser, it redirects to script.php (or whatever) on the
server with THAT string as the argument. Which, by querying for that row in a
SQL database or something, brings up my name in the company's database.....
am I on the right track here?
Yes, that's basically how it works. Webservers typically use rewrite
rules to move path components to script parameters, so a URL like:

https://www.example.com/paybill/e2gbm853dc

could be translated to:

https://www.example.com/paybill.php?id=e2gbm853dc

and then the script does the database lookup to find you.
--
Barry Margolin
Arlington, MA
Ivan Shmakov
2017-06-29 18:33:43 UTC
Permalink
[Cross-posting to news:comp.infosystems.www.misc, for reasons.]
Post by b***@hotmail.com
I just got a bill on my phone, which said "To pay this bill - go to
www.<whatever>" . When I went to the site - it said stuff like
"Welcome Mr. John Doe", ie. it *knew from the URL* that it was me!
I'm kind of trying to figure out how this was architected - can you
guys help? :)
MY brain suggested something like this: whatever was after the "/"
in the URL (something like e2gbm853dc or whatever) was an ARGUMENT -
when someone types that in to the browser, it redirects to
script.php (or whatever) on the server with THAT string as the
argument. Which, by querying for that row in a SQL database or
something, brings up my name in the company's database..... am I on
the right track here?
Yes, that's basically how it works. Webservers typically use rewrite
https://www.example.com/paybill/e2gbm853dc
https://www.example.com/paybill.php?id=e2gbm853dc
and then the script does the database lookup to find you.
Or the Web server could be configured so that whenever it sees a
URI starting with "/paybill", it starts (or contacts, for
FastCGI) the script, which then has access to either the
original URI in its entirety, or at least the part after the
script's name.

I'm pretty sure that configuring Apache in such a way may be a
matter of a couple of lines. (Like SetHandler, etc.)
--
FSF associate member #7257 np. Most Wonderful of Nights -- Aftermath
Eli the Bearded
2017-06-29 22:31:49 UTC
Permalink
Post by Ivan Shmakov
[Cross-posting to news:comp.infosystems.www.misc, for reasons.]
Hellow from ciwm!
Post by Ivan Shmakov
Yes, that's basically how it works. Webservers typically use rewrite
https://www.example.com/paybill/e2gbm853dc
https://www.example.com/paybill.php?id=e2gbm853dc
That sounds like such an old-fashioned way to do it. Why bother with a
rewrite when you can just use the original?
Post by Ivan Shmakov
Or the Web server could be configured so that whenever it sees a
URI starting with "/paybill", it starts (or contacts, for
FastCGI) the script, which then has access to either the
original URI in its entirety, or at least the part after the
script's name.
In modern web frameworks, the local part of the URL (the URI) is called
a "route" and the routing table in the framework is consulted. Consider
Ruby on Rails:

http://guides.rubyonrails.org/routing.html

The very first example is relevant here. Some other frameworks might
solve this by having the server always return the same page for all of
/paybill/*, and a javascript routing table examine the URL and look up
the content to fill in to the page. For example, Ember:

https://guides.emberjs.com/v2.12.0/routing/defining-your-routes/

Look at the Dynamic Routes section.

Elijah
------
the wab has so many ways to ensnare you now
b***@hotmail.com
2017-07-01 10:19:31 UTC
Permalink
Ok, thanks for that info, Elijah and others,...but just talking about SEO for a moment here..... - assuming that page had to be put on Google, how would Google *find* the site.com/paybill/e2gbm .... page? Does it just hit site.com's server and just go to all URI's alphabetically?!! like. site.com/a , site.com/b, etc. etc? That sounds impossible (and bloody ridiculous!).

....I'm getting confused as to what HTTP is going back and forth, through all this....
Robert Wessel
2017-07-01 17:49:30 UTC
Permalink
Post by b***@hotmail.com
Ok, thanks for that info, Elijah and others,...but just talking about SEO for a moment here..... - assuming that page had to be put on Google, how would Google *find* the site.com/paybill/e2gbm .... page? Does it just hit site.com's server and just go to all URI's alphabetically?!! like. site.com/a , site.com/b, etc. etc? That sounds impossible (and bloody ridiculous!).
Amongst other things, search engines visit sites on a regular basis
and follow all the links they find. So if site.com's home page has
links to site.com/a and site.com/b, it'll then go scan those pages
(and then follow any links on *those* pages), but it wouldn't try
site.com/c (unless such a link existed somewhere). It will also note
when it finds links to someothersite.com/xyz.

As to finding the site in the first place... Well, Google will find
links to a new site eventually (assuming any are created, of course),
as well as being able to scan to "obvious" domain names from listings
in the zone files (let's say you registered bit-naughtly.com, you
might expect a scan from Google for bit-naughtly.com/,
www.bit-naughtly.com/index.html, and similar likely names for your
home page), but that might take some time. So you can also submit a
site to Google directly to be indexed (or reindexed).

You can also help Google in various ways depending on the content of
your site. For example, site that bury many of their links inside
Javascript may be hard for the crawler to follow, so you may want to
submit an explicit site map to Google..

See:

https://support.google.com/webmasters/answer/6259634?hl=en

Other search engines do similar things.

You can also ask the search engines limit their crawling of your site
in various ways by putting parameters in your robots.txt file.

As to SEO, well, the algorithms are secret (mainly to try to prevent
people from gaming them), but there are clearly things like frequency
of reference (other sites pointing to a site*) and frequency of use
(people actually going from a search to a site) that factor into the
ranking algorithms. There's clearly also analysis of "real"
relevance, trying to filter out pages/site that just have a bunch of
keywords to match, vs. site that appear to be actually talking about
the subject in question.



*And that used to be a big part of what the SEO "services" offered -
they maintained hundreds or thousands of web sites that consisted of
little more than lists of links to the websites they were being paid
to "optimize". In the simpler days the search engines assumed that
many links to a site meant the site was useful. These days finding a
link to your site on such a list is actually a *negative* for your
ranking. It's really a quite active little arms race.
Post by b***@hotmail.com
....I'm getting confused as to what HTTP is going back and forth, through all this....
Loading...