How to Post Long URL in PHP - php

How can I post a full URL in PHP?
For example:
I have a form allowing individuals to submit a long url. The resultant page is /index.php?url=http://www.example.com/
This is fine for short URLs, but for very long and complex URLs (like those from Google Maps) I need to know how to keep all of the data associated with variable url.

You need to percent encode the string — otherwise characters which have special meaning in URIs will have that special meaning instead of being treated as data.
http://php.net/urlencode
If users submit this data via a form, then it will be automatically encoded.
If you plan to include the URI in a link in an HTML document, then don't forget to convert special characters to HTML entities.

You sort of answer your own question:
How can I post a full URL in PHP?
If very long URLs are getting truncated by the users' browsers, your only option is to re-work your system to POST the URL to your script, as opposed to passing it in the query string.
If there is some condition that frustrates the use of a POST request, you should update your question with more detail about what your system does.

Related

How to allow # ? & characters in URL while still allowing query strings

I have a site that allows users to create a page based on user input example.com/My Page
The problem is if they create a url like example.com/H & E Photos or example.com/#1 Fan Club
Once php decodes the url, it tries to parse those characters into a hash (or a query string in the case of ?)
In my .htacess I am doing this ([^/]+?)
What is the typical way of handling a situation like this? Ideally, without going to an id system (example.com/131234121). Poor planning on my part :(
EDIT. Talking about PHP here. url is encoded when it hits the server, php decodes before parse regex and url
If you are using PHP to create/handle storing entries for user-entered-URLs then use htmlentities on the string before trying to handle it.
https://www.php.net/manual/en/function.htmlentities.php
https://www.w3schools.com/php/func_string_htmlentities.asp
Apparently, what I was looking for was a rewrite flag.
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriteflags
B Escape non-alphanumeric characters before applying the transformation.
This allows you to send percent-encoded strings to the URL without them being decoded beforehand.
So it was actually an apache thing and not PHP. Sorry for the misleading question.

How to encode/decode international URLs for presentation in PHP

I'm struggling to find a solution (built in or library) to the problem of decoding a URL containing percent-encoded characters outside the ASCII range.
As far as I understand RFC 3986 we shouldn't decode a URL as a whole, without first breaking it into components. However, this seems to be what browsers do with "international" characters. For example if I paste this URL into the address bar of Google Chrome:
http://www.example.com/?x=7%26z%3D6&q=%C3%A9
It is rendered as this:
http://www.example.com/?x=7%26z%3D6&q=é
So how do I do this with PHP without implementing my own url decoder? The built-in functionality (i.e urldecode) would return:
http://www.example.com/?x=7&z=6&q=é
Which is wrong (because there are now 3 query parameters) but expected (because urldecode is not designed to be used on entire urls)
I would like to be able to replicate the browser behaviour when displaying links in my application: in the href attribute I'll use the percent encoded form but in the anchor itself I'll use the "pretty" form.

Value with # in query string does not receive full data

I have one url with one code.
http://www.example.com/exam.php?id=rteter#443545
Now when I click this URL, the value of the id is rteter, means it returns me only portion of code before #.
I have not sent the link with urlencode so please do not give that solutions. Links are already sent, is they any way by which I can get the full value in my php code?
Martha
The # character indicates the start of the fragment identifier and is handled client side. You need to represent it as %23 if you want it sent to the server.
If you are generating query string parameters programatically in PHP, use the urlencode function.
Check out this post on stackoverflow:
Can I read the hash portion of the URL on my server-side application (PHP, Ruby, Python, etc.)?
It might cover your question.
use url quote
http://www.example.com/exam.php?id='rteter%23443545'
http://php.net/manual/en/function.urlencode.php

How can I accept a hash mark in a URL via $_GET?

From what I have been able to understand, hash marks (#) aren't sent to the server, so it doesn't seem likely that I will be able to use raw PHP to parse data like in the URL below:
index.php?name=Ben&address=101 S 10th St Suite #301
I'm looking to pre-populate form fields with this $_GET data. How would I do this with Javascript (or jQuery), and is there a fallback that wouldn't break my form for people not using Javascript? Currently if there is a hash (usually in the address field), everything after that is not parsed in or stored in $_GET.
You can encode the hash as you should urlencode(in php) or encodeURIComponent(in JavaScript).
The "hash" is not part of the request, which is why your script never sees it.
Like webdestroya said, you'll need to send a request with the URL
index.php?name=Ben&address=101%20S%2010th%20St%20Suite%20%23301
If you're using HTML forms, then the string value will be auto-urlencoded when you submit the form.
the user will be clicking a link from an email and will want to see the hash mark rendered in the email
You need to encode the link to what Ben quoted before you stick it in the e-mail. What you currently have is not a URL at all.
You can optionally encode a space to + instead of %20 in the context of query parameters but you absolutely cannot include a raw space, because it is a defining characteristic of URLs that they don't have spaces in. If you type a space in a URL in a web browser it will quietly fix up the mistake, but an e-mail client can't pick out a URL from plain text if it's full of spaces.
There is sometimes an alternative function which encodes spaces to + instead of %20. Normally this is best avoided as + isn't valid in all circumstances, but if prefer:
index.php?name=Ben&address=101+S+10th+St+Suite+%23301
then you'd use PHP's urlencode function instead of the more standard rawurlencode.
Either way, you must encode the hash to %23, because otherwise a hash in an HTTP URL means the fragment identifier (the part of the page to scroll the browser to). This is not part of the address of the page itself; it is not even passed from the browser to the server, so you certainly cannot retrieve it—from $_GET or any other interface.
There are many other characters in a component like an address that must be %-encoded before being inserted into a URL string, or they'll leave you with an invalid or otherwise non-functional URL. If all that %23 business looks funny in a URL... well, you'll have to live with it. That's what URLs have always looked like.
I usually store the hash on a cookie onunload
ej:
window.unload = function(){
if(document.location.hash) setCoockie('myhash',document.location.hash);
};

When using a unique alphanumeric string for a short url, is it better to store the created string in the database or encode/decode on the fly?

I want to create shortened links for specific pieces of content on my site. To view these pages now, I pull the relevant content via the content ID passed via GET (ie, mysite.com/content/?id=332). To obfuscate the ID, I want to use base64 to encode and decode it into a short alphanumeric string (like 34sa6), which I already know how to do.
My question is this: does it make more sense to store this string as a database field on creation of each piece of content, or simply decode the string on the fly when a user visits mysite.com/content/34sa6 (which means visiting mysite.com/content/?id=332 will also load the correct page). If I store this instead, it will become the defacto primary key for my purposes, as all related content will be queried based on it, so just trying to figure out the wisest way to do it.
If you decode and encode it during the request, you can't switch to a different method of encoding in the future.
Storing it in the database allows you to change the encoding whenever you want, because when the full URL needs to be retrieved, the script only looks for a matching database entry.

Categories