Comment obtenir le hachage d'URL (#) du côté serveur

133

Je sais que du côté client (javascript), vous pouvez utiliser windows.location.hash mais je n'ai pas trouvé de toute façon pour accéder du côté serveur.

Ricky Supit
la source
avez-vous trouvé un moyen de résoudre ce problème, j'ai des signets avec has dans l'url et je veux accéder au texte après le hachage côté serveur?
dotnetcoder le
Les réponses expliquent que cela n'est pas disponible sur le serveur, car il n'est interprété que par l'agent utilisateur. J'essayais de changer l'onglet actif, ce que j'essayais de faire côté serveur. J'ai fini par le faire côté client à la place.
Ricky Supit

Réponses:

134

Nous avons eu une situation où nous devions conserver le hachage d'URL dans les post backs ASP.Net. Comme le navigateur n'envoie pas le hachage au serveur par défaut, la seule façon de le faire est d'utiliser du Javascript:

  1. Lorsque le formulaire est soumis, saisissez le hash ( window.location.hash) et stockez-le dans un champ de saisie caché côté serveur. Mettez-le dans un DIV avec un identifiant de " urlhash" afin que nous puissions le trouver facilement plus tard.

  2. Sur le serveur, vous pouvez utiliser cette valeur si vous avez besoin d'en faire quelque chose. Vous pouvez même le changer si vous en avez besoin.

  3. Au chargement de la page sur le client , vérifiez la valeur de ce champ masqué. Vous voudrez le trouver par le DIV dans lequel il est contenu car l'ID généré automatiquement ne sera pas connu. Oui, vous pourriez faire une supercherie ici avec .ClientID mais nous avons trouvé plus simple d'utiliser simplement le wrapper DIV car il permet à tout ce Javascript de vivre dans un fichier externe et d'être utilisé de manière générique.

  4. Si le champ de saisie masqué a une valeur valide, définissez-la comme hachage d'URL ( window.location.hash again) et / ou effectuez d'autres actions.

Nous avons utilisé jQuery pour simplifier la sélection du champ, etc ... dans l'ensemble cela finit par être quelques appels jQuery, un pour sauvegarder la valeur, et un autre pour la restaurer.

Avant de soumettre:

$("form").submit(function() {
  $("input", "#urlhash").val(window.location.hash);
});

Au chargement de la page:

var hashVal = $("input", "#urlhash").val();
if (IsHashValid(hashVal)) {
  window.location.hash = hashVal;
}

IsHashValid()peut vérifier " undefined" ou d'autres choses que vous ne voulez pas gérer.

Assurez-vous également de l'utiliser de $(document).ready()manière appropriée, bien sûr.

Chris
la source
4
Excellente solution, mais qu'en est-il de la demande GET?
Warlock
2
@Chris - Mais comment l'événement de soumission de formulaire est-il appelé lorsque vous collez simplement l'URL dans un autre navigateur (car il ne s'agit que d'une requête GET)?
KrishPrabakar
@Warlock, indépendamment de get / post, cela fonctionnera puisque vous stockez le hachage dans un champ caché.
KMX
83

RFC 2396 section 4.1:

Lorsqu'une référence URI est utilisée pour effectuer une action de récupération sur la ressource identifiée, l'identificateur de fragment facultatif, séparé de l'URI par un caractère hachuré ("#"), se compose d'informations de référence supplémentaires à interpréter par l'agent utilisateur après la récupération. l'action a été effectuée avec succès . En tant que tel, il ne fait pas partie d'un URI, mais est souvent utilisé en conjonction avec un URI.

(italiques ajoutés)

Mauricio Scheffer
la source
3
Je suis surpris. J'ai beaucoup lu sur SPA et je ne le savais pas. Donc, le navigateur envoie tellement d'informations sensibles mais pas le hachage ?? Je pense qu'il devrait dans le futur .. au moins comme un en-tête HTTP séparé. Ceci est lié: onebigfluke.com/2015/01/…
bodrin
42

C'est parce que le navigateur ne transmet pas cette partie au serveur, désolé.

Julien Oster
la source
7

Le seul choix est probablement de le lire côté client et de le transférer manuellement sur le serveur (GET / POST / AJAX). Cordialement Artur

Vous pouvez également voir comment jouer avec le bouton de retour et l'historique du navigateur sur Malcan


la source
3

Juste pour écarter la possibilité que vous n'essayiez pas réellement de voir le fragment sur un GET / POST et que vous vouliez réellement savoir comment accéder à cette partie d'un objet URI que vous avez dans votre code côté serveur, c'est sous Uri. ( Documents MSDN ).

Patridge
la source
8
IE8, Chrome et Firefox n'enverront pas tous le hachage au serveur; ainsi, Uri.Fragment est toujours une chaîne vide si vous examinez Request.Url.Fragment côté serveur (comme dans les réponses ci-dessus.)
zcrar70
0

Solution possible pour les requêtes GET:

Nouveau format de lien: http://example.com/yourDirectory?hash=video01

Appelez cette fonction vers le haut du contrôleur ou http://example.com/yourDirectory/index.php:

function redirect()
{
    if (!empty($_GET['hash'])) {
        /** Sanitize & Validate $_GET['hash']
               If valid return string
               If invalid: return empty or false
        ******************************************************/
        $validHash = sanitizeAndValidateHashFunction($_GET['hash']);
        if (!empty($validHash)) {
            $url = './#' . $validHash;
        } else {
            $url = '/your404page.php';
        }
        header("Location: $url");
    }
}
webaholik
la source