This is url element www.example.com/title=&location=new york&search=?jobid=e0e1ea2a0f2fb962af54d0eb3
<?php
$_SERVER['REQUEST_URI'];
<?php echo "title=" .$_GET['title'];
echo "&location=" .$_GET['location'];
echo "&search=";
echo "jobid" .$_GET['jobid'];
?>
I got the result title=&location=new york&search= and Warning: Undefined array key "jobid"
could you please let me know how can I solve it?

kumerbakul
You should be using the POST form method not the GET method.
It doesn't use a visible querystring.
It's more secure.

$title = "";
$location = "";
$search = "";
$jobid = "";

$contlen = $_SERVER['CONTENT_LENGTH'];

if ($contlen > 0){
    $title = $_REQUEST['title'];
    $location = $_REQUEST['location'];
    $search = $_REQUEST['search'];
    $jobid = $_REQUEST['jobid'];
}

    RayPooley You should be using the POST form method not the GET method.
    It doesn't use a visible querystring.
    It's more secure.

    Assuming that security is necessary. It's also unbookmarkable.

    Incidentally, @kumerbakul, the first line in the PHP, $_SERVER['REQUEST_URI'];, isn't doing anything.

      Weedpacket
      Secure design should be the default position not an option.
      It costs nothing to implement secure solutions.
      It's the same with flexibility and scaleability.

        RayPooley The GET method exists for a reason, so does the POST method.
        Secure should be the default option, but you have to be clear on what you're securing and why, or it won't work.

          Weedpacket
          "The GET method exists for a reason".

          There's no legitimate reason why the GET method should exist at all and should have been deprecated a long time ago.
          There is no point in implementing clientside form validation because the GET method allows you to bypass it.
          In fact with the GET method you don't even have to use the form at all. The URL parameters sent along with the data are not only visible to everyone in the browser address bar, but are also stored unencrypted in the browser history, cache, and log file of the server. These problems are well documented. It only remains today for legacy reasons. Supporting old websites.

          "... but you have to be clear on what you're securing and why, or it won't work.".

          I have no idea what that even means.
          But you are actually arguing in favour of developing and implementing unsecure systems.
          I find that ridiculous.

            RayPooley I have no idea what that even means.

            And yet you have already formed an opinion on it.

            RayPooley There is no point in implementing clientside form validation because the GET method allows you to bypass it.

            There is every point in implementing clientside form validation because it makes for better performance for the user. So what if they can use the GET method to bypass it. They can bypass it via the POST method. They don't even need to load the page if they want to bypass it. Doesn't matter if the endpoint uses GET or POST or PUT for that matter. Clientside validation is a user convenience. The only validation that matters is server-side.

            RayPooley The URL parameters sent along with the data are not only visible to everyone in the browser address bar, but are also stored unencrypted in the browser history, cache, and log file of the server.

            And unless that matters for some reason, so what?

                    13 days later

                    RayPooley There's no legitimate reason why the GET method should exist at all

                    Yes there is. GET operations are intended for read requests that do not change the state of the server. E.g., if you were asking for a restaurant menu. The endpoints that respond to GET requests are intended to provide information. They can typically be bookmarked, cached, shared via email or text message, etc. If you are authenticated, what you see might differ from what others see. Consider reading what shrewder minds than us might have to say about the GET method.

                    POST operations, on the other hand are meant to provide data to the server, and possibly alter the server's state. You may have noticed that your browser behaves differently when you are viewing the output of a POST operation. It does that for a reason.

                        Write a Reply...