URL avant et encore revenir 200 302 pas dans ASPX

Je veux cette page pour revenir 200 tout en envoyant encore la redirection ...URL avant et encore revenir 200 302 pas dans ASPX

<script> 
    sub page_load 
     'Get the parameters 
     dim content As String 
     content = request.querystring("text") 
     response.redirect ("http://100.200.100.10/test1/Default.aspx?CommandParm=" + content) 
    end sub 
</script> 
<html> 
    <head> 
    </head> 
    <body> 
     <form runat="server"> 
     </form> 
    </body> 
</html>

Source

2008-10-28 Anonymous

Aucun chemin avec Response.Redirect(). Je pense. Peut-être réglage Response.Status = "200 OK" après avoir appelé Redirect() fonctionne, je n'ai jamais essayé.

Vous pourriez truquer en définissant l'en-tête "Location" manuellement dans une réponse autrement vide. Je ne sais pas à quoi cela sert, cependant. ;-)

Response.AddHeader("Location", "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content) 
Response.End()

(Et, pour l'enregistrement: Vous seriez la production d'une constellation d'en-tête HTTP invalide ne doit pas casser quoi que ce soit, mais quand même..)

Source

2008-10-28 06:00:04 Tomalak

Vous pouvez obtenir cette page pour être redirigé par javascript

Tout d'abord, créer le javascript dynamique en faisant la chaîne suivante

<script type"text/javascript"> 
<!-- 
function redirect() 
{ 
    window.location = "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content 
} 
//--> 
</script>

en second lieu, ajoutez les Javas cript à l'en-tête de la page en cours.

Ensuite, ajoutez le javascript au corps

mybody.Attributes.Add("onload", "redirect()");

Lorsque vous naviguez sur la page en cours, il vous renvoie HTTP 200, et après l'événement onload déclenche le navigateur appellera redirect() et votre navigation sera dans la page cible.

Juste curieux, pourquoi avez-vous besoin de ça ?!

Source

2008-10-28 06:10:49

Merci. Je sais que c'est un peu idiot. Mais la requête HTTP a un certain nombre de paramètres que je ne peux pas influencer. L'application vers laquelle je redirige ne peut prendre qu'un argument nommé. Donc, je passe essentiellement à une URL différente. N'avoir aucune expérience de l'aspirateur si poignarder dans l'obscurité. –

@ eyelidlessness @

Je suis d'accord, il semble que le choix de la facilité d'utilisation pauvre, mais je suis en espérant qu'il est une solution pour un problème qui ne peut être fixé directement.

Étant donné que, essayez un META refresh, par exemple,

<meta http-equiv="refresh" content="5;url=http://example.com/"/>

et embed un message expliquant ce qui se passe à l'utilisateur malchanceux qui atterrit sur cette page.

Je ne me suis probablement pas expliqué en postant une question. C'est en fait une transaction B2B. Il n'y a pas d'utilisateur final avec un navigateur. Un tiers envoie le HTTP GET. Tout ce que nous voulons faire, c'est le transmettre comme une transaction légitime.

Ensuite, vous devriez envoyer un 301 ou 302 - c'est le but exact pour lequel ils ont été conçus.

Source

2008-10-28 10:00:38

Je ne me suis probablement pas expliqué en postant une question. C'est en fait une transaction B2B. Il n'y a pas d'utilisateur final avec un navigateur. Un tiers envoie le HTTP GET. Tout ce que nous voulons faire, c'est le transmettre comme une transaction légitime. –

Ensuite, vous devriez envoyer un 301 ou 302 - c'est le but exact pour lequel ils ont été conçus. –

Vous ne pouvez pas avoir les deux: Rediriger et statut 200.

RFC2616 dit à propos status code 200:

10.2.1 200 OK

La demande a réussi.Les informations retournées avec la réponse dépend de la méthode utilisée dans la demande, par exemple:

GET: une entité correspondant à la ressource demandée est envoyée dans la réponse;

HEAD: les champs d'en-tête d'entité correspondant à la ressource demandée sont envoyés dans la réponse sans aucun corps de message;

POST: entité décrivant ou contenant le résultat de l'action;

TRACE: entité contenant le message de requête tel qu'il est reçu par le serveur final.

Il n'y a donc pas de place pour rediriger autre que l'envoi d'un contenu qui est interprété par l'agent utilisateur, par exemple JavaScript dans un navigateur

Et this is the part dans la spécification qui indique sur la redirection en utilisant des codes d'état 301, 302 ou 303:

10.3.2 301 Moved Permanently

La ressource demandée a été attribué une nouvelle URI permanente et toute référence future à cette ressource DEVRAIT utiliser l'un des URI retournés. Les clients disposant de fonctionnalités d'édition de liens doivent automatiquement relier les références à l'URI de demande à une ou plusieurs des nouvelles références renvoyées par le serveur, si possible. Cette réponse peut être mise en cache sauf indication contraire.

Le nouvel URI permanent DEVRAIT être donné par le champ Emplacement dans la réponse. Sauf si la méthode de requête était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers le ou les nouveaux URI. Si le code d'état 301 est reçu en réponse à une demande autre que GET ou HEAD, l'agent utilisateur NE DOIT PAS rediriger automatiquement la demande à moins qu'elle ne puisse être confirmée par l'utilisateur, car cela pourrait modifier les conditions dans lesquelles la demande a été publiée.

Remarque: Lors de la redirection automatique d'une requête POST après la réception d'un code d'état 301, certains agents utilisateurs HTTP/1.0 existants la modifient par erreur en une requête GET.

10.3.3 302 Trouvé

La ressource demandée réside temporairement dans un autre URI. Étant donné que la redirection peut être modifiée à l'occasion, le client DEVRAIT continuer à utiliser l'URI de demande pour les demandes futures. Cette réponse est uniquement disponible si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.

L'URI temporaire DEVRAIT être donné par le champ Emplacement dans la réponse. Sauf si la méthode de requête était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers le ou les nouveaux URI. Si le code d'état 302 est reçu en réponse à une requête autre que GET ou HEAD, l'agent utilisateur NE DOIT PAS rediriger automatiquement la requête à moins qu'elle ne puisse être confirmée par l'utilisateur, car cela pourrait modifier les conditions sous lesquelles la demande a été publiée.

Remarque: RFC 1945 et RFC 2068 spécifient que le client n'est pas autorisé à modifier la méthode sur la demande redirigée. Toutefois, la plupart des implémentations d'agent d'utilisateur existantes traitent 302 comme s'il s'agissait d'une réponse 303, en effectuant une opération GET sur la valeur de champ Emplacement quelle que soit la méthode de requête d'origine. Les codes d'état 303 et 307 ont été ajoutés pour les serveurs qui souhaitent rendre clair quel type de réaction est attendu du client.

10.3.4 303 Voir Autres

La réponse à la demande peut être trouvé sous un autre URI et doit être récupéré à l'aide d'une méthode GET sur cette ressource. Cette méthode existe principalement pour permettre la sortie d'un script activé par POST pour rediriger l'agent utilisateur vers une ressource sélectionnée. Le nouvel URI n'est pas une référence de remplacement pour la ressource initialement demandée. La réponse 303 NE DOIT PAS être mise en cache, mais la réponse à la deuxième demande (redirigée) peut être mise en cache.

Les différents URI DEVRAIENT être donnés par le champ Emplacement dans la réponse. Sauf si la méthode de requête était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers le ou les nouveaux URI.

Remarque: De nombreux agents utilisateur pré-HTTP/1.1 ne comprennent pas l'état 303. Lorsque l'interopérabilité avec de tels clients est une préoccupation, le code d'état 302 peut être utilisé à la place, puisque la plupart des agents utilisateurs réagissent à une réponse 302 comme décrit ici pour 303.

Source

2008-11-03 20:12:11 mkoeller

URL avant et encore revenir 200 302 pas dans ASPX

Répondre

Questions connexes