J'ai développé une application web PHP. Je donne la possibilité à l'utilisateur de mettre à jour plusieurs numéros en une seule fois. En faisant cela, l'utilisateur rencontre parfois cette erreur. Existe-t-il un moyen d'augmenter la longueur de l'URL dans Apache ?
Sous Apache, la limite est une valeur configurable, LimitRequestLine . Changez cette valeur pour une valeur supérieure à sa valeur par défaut de 8190 si vous souhaitez prendre en charge un URI de demande plus long. La valeur est en /etc/apache2/apache2.conf . Sinon, ajoutez une nouvelle ligne ( LimitRequestLine 10000 ) sous AccessFileName .htaccess .
Cependant, notez que si vous vous heurtez à cette limite, vous abusez probablement de l'option GET pour commencer. Vous devriez utiliser POST pour transmettre ce genre de données -- d'autant plus que vous concédez même que vous l'utilisez pour mettre à jour des valeurs. Si vous vérifiez le lien ci-dessus, vous remarquerez qu'Apache dit même "Dans des conditions normales, la valeur ne doit pas être modifiée par rapport à la valeur par défaut".
J'ai d'abord essayé d'utiliser POST, mais il s'agit d'une opération de mise à jour de la base de données, et je rafraîchis la page d'origine en utilisant les valeurs qui ont été initialement publiées sur cette page.
JPro : Mettre à jour une base de données est plus ou moins la raison exacte que vous utiliseriez POST . Rien dans l'utilisation de POST ne vous empêche de remplir le même formulaire avec les champs qui viennent d'être postés, donc je ne suis pas sûr de ce que vous voulez dire par là.
@JPro : La technique habituelle dans ce cas est de POST vers la même page. Le gestionnaire de la page (qui peut être le même code pour GET et POST) vérifie d'abord les paramètres POST, les traite s'il les trouve, puis renvoie la page avec les valeurs appropriées remplies, qui seront soit les valeurs mises à jour (si POST et la mise à jour réussit), soit les valeurs originales (si GET, ou si POST et la mise à jour échoue). Si la mise à jour échoue, vous pouvez même avoir des messages d'erreur par champ décrivant l'échec.
Sur la base de la réponse de John, j'ai changé la requête GET en requête POST. Cela fonctionne, sans avoir à modifier la configuration du serveur. J'ai donc cherché comment mettre cela en œuvre. Les pages suivantes m'ont été utiles :
Exemple de jQuery Ajax POST avec PHP (Notez la remarque sur la désinfection des données affichées) et
http://www.openjs.com/articles/ajax_xmlhttp_using_post.php
En fait, la différence est que la requête GET contient l'url et les paramètres dans une seule chaîne de caractères, puis envoie null :
http.open("GET", url+"?"+params, true);
http.send(null);alors que la requête POST envoie l'url et les paramètres dans des commandes séparées :
http.open("POST", url, true);
http.send(params);Voici un exemple concret :
ajaxPOST.html :
<html>
<head>
<script type="text/javascript">
function ajaxPOSTTest() {
try {
// Opera 8.0+, Firefox, Safari
ajaxPOSTTestRequest = new XMLHttpRequest();
} catch (e) {
// Internet Explorer Browsers
try {
ajaxPOSTTestRequest = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
ajaxPOSTTestRequest = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {
// Something went wrong
alert("Your browser broke!");
return false;
}
}
}
ajaxPOSTTestRequest.onreadystatechange = ajaxCalled_POSTTest;
var url = "ajaxPOST.php";
var params = "lorem=ipsum&name=binny";
ajaxPOSTTestRequest.open("POST", url, true);
ajaxPOSTTestRequest.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
ajaxPOSTTestRequest.send(params);
}
//Create a function that will receive data sent from the server
function ajaxCalled_POSTTest() {
if (ajaxPOSTTestRequest.readyState == 4) {
document.getElementById("output").innerHTML = ajaxPOSTTestRequest.responseText;
}
}
</script>
</head>
<body>
<button onclick="ajaxPOSTTest()">ajax POST Test</button>
<div id="output"></div>
</body>
</html>ajaxPOST.php :
<?php
$lorem=$_POST['lorem'];
print $lorem.'<br>';
?>Je viens d'envoyer plus de 12 000 caractères sans aucun problème.
J'ai une solution de rechange simple.
Supposons que votre URI ait une chaîne de caractères stringdata qui est trop long. Vous pouvez simplement le décomposer en plusieurs parties en fonction des limites de votre serveur. Soumettez ensuite la première, dans mon cas pour écrire un fichier. Puis soumettez les suivantes pour ajouter des données à celles déjà ajoutées.
Pouvez-vous fournir un exemple ? Je peux voir comment vous divisez la chaîne quand elle est générée par l'utilisateur...
Une solution de contournement très bon marché. Il est préférable de reconsidérer le problème du domaine !
Cela ne mérite pas d'avoir autant de votes négatifs. Il existe certainement des situations dans lesquelles la soumission de plusieurs demandes peut être une solution de rechange acceptable. Il est vrai que la qualité de la réponse est un peu faible, mais il faut s'y attendre de la part d'un utilisateur qui est tout nouveau sur SO. Montrons un peu d'amour et offrons un retour d'information au lieu de descendre les nouveaux venus qui ne "comprennent" pas encore l'OS !
J'ai obtenu cette erreur après avoir utilisé $.getJSON() de JQuery. Je viens de changer pour post :
data = getDataObjectByForm(form);
var jqxhr = $.post(url, data, function(){}, 'json')
.done(function (response) {
if (response instanceof Object)
var json = response;
else
var json = $.parseJSON(response);
// console.log(response);
// console.log(json);
jsonToDom(json);
if (json.reload != undefined && json.reload)
location.reload();
$("body").delay(1000).css("cursor", "default");
})
.fail(function (jqxhr, textStatus, error) {
var err = textStatus + ", " + error;
console.log("Request Failed: " + err);
alert("Fehler!");
});
Un extrait de la RFC 2616 : Protocole de transfert hypertexte -- HTTP/1.1 :
El POST est utilisée pour demander au serveur d'origine d'accepter l'entité entité incluse dans la demande comme un nouveau subordonné de la ressource identifiée par le Request-URI dans la Request-Line. La méthode POST est conçue pour permettre à une méthode uniforme de couvrir les fonctions suivantes :
- Annotation des ressources existantes ;
- Poster un message sur un tableau d'affichage, un groupe de discussion, une liste de diffusion, ou un groupe d'articles similaires ;
- Fournir un bloc de données, tel que le résultat de la soumission d'un formulaire, à un processus de traitement des données ;
- Extension d'une base de données par une opération d'ajout.
L'expéditeur initial a indiqué que les enregistrements étaient en cours de mise à jour. Pour les mises à jour, il est recommandé d'utiliser POST ou PUT et non GET. Mais, bien sûr, il se peut que la limite maximale de l'URL soit dépassée lors de la récupération des enregistrements à afficher avant la mise à jour, et la méthode GET est alors appropriée, mais elle peut échouer à cause de cette limite. L'auteur du message d'origine n'a pas mentionné à quel stade le problème se pose, on peut donc supposer que c'est pendant la mise à jour elle-même, mais on ne peut pas en être sûr...
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Si vous rencontrez cette erreur sur un serveur Windows et/ou dans une application IIS / ASP.NET, consultez la question : stackoverflow.com/q/23237538/12484