La publication ne fonctionne pas avec la page aspx comme document par défaut

Si je navigue sur http: //localhost/edumatic3/trunk/login/accesscode/Default.aspx , ma publication fonctionne. Toutefois, si je navigue jusqu’à http: // localhost / edumatic3 / trunk / login / accesscode / (avec Default.aspx défini comme document par défaut), ma publication ne fonctionne pas.

Est-il possible de faire ce travail? Ou dois-je supprimer le document par défaut et forcer les utilisateurs à accéder à http: //localhost/edumatic3/trunk/login/accesscode/default.aspx ?

METTRE À JOUR:

Code (partie):

<asp:ImageButton ID="continueImageButton" runat="server" ValidationGroup="continue" OnClick="ContinueImageButton_Click" AlternateText=""/>

Code derrière (partie):

 protected void Page_Load(object sender, EventArgs e) { Log.Debug("Page_Load(...)"); Log.Debug("Page_Load(...) :: PostBack = " + IsPostBack); if (!IsPostBack) { continueImageButton.ImageUrl = "~/App_Themes/" + base.Theme + "/images/" + Resources.login.btn_continue; } } ///  /// Continue Image Button Click Handler ///  ///  ///  protected void ContinueImageButton_Click(object sender, EventArgs e) { .... 

Lorsque je clique sur ImageButton, Page_Load est déclenché et IsPostBack est faux … Normalement, cela devrait être vrai. ContinueImageButton_Click (…) n’est pas du tout déclenché.

En HTML (en partie):

  

Http demande:

 POST /edumatic3/trunk/login/accesscode/ HTTP/1.1 Host: localhost Referer: http://localhost/edumatic3/trunk/login/accesscode/ Content-Length: 1351 Cache-Control: max-age=0 Origin: http://localhost User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.215 Safari/535.1 Content-Type: application/x-www-form-urlencoded Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl,en-US;q=0.8,en;q=0.6,fr;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 ASP.NET_SessionId=33yal3buv310y2etuj33qghg; CurrenUICulture=en-us __EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDw... 

J’ai pensé essayer de reproduire cela, et vous avez tout à fait raison. Il se casse sans le default.aspx avec un exemple très simple que vous avez fourni. En regardant le HTML, la raison est assez claire. C’est parce que l’atsortingbut d’action est vide.

Une recherche rapide a révélé cela, ASP.NET 4 Breaking Changes (voir Les gestionnaires d’événements peuvent ne pas être déclenchés dans un document par défaut en mode intégré IIS 7 ou IIS 7.5).

ASP.NET 4 restitue désormais la valeur d’atsortingbut d’action de l’élément de formulaire HTML en tant que chaîne vide lorsqu’une demande est adressée à une URL sans extension contenant un document par défaut. Par exemple, dans les versions antérieures d’ASP.NET, une demande adressée à http://contoso.com entraînerait une demande sur Default.aspx. Dans ce document, la balise d’ouverture du formulaire serait rendue comme dans l’exemple suivant:

 

Dans ASP.NET 4, une requête à http://contoso.com entraîne également une demande à Default.aspx. Toutefois, ASP.NET affiche désormais la balise de formulaire d’ouverture HTML comme dans l’exemple suivant:

 

Cette différence dans la manière dont l’atsortingbut action est rendu peut entraîner des modifications subtiles dans la manière dont une publication de formulaire est traitée par IIS et ASP.NET. Lorsque l’atsortingbut d’action est une chaîne vide, l’object IIS DefaultDocumentModule crée une demande enfant à Default.aspx. Dans la plupart des conditions, cette demande enfant est transparente pour le code d’application et la page Default.aspx s’exécute normalement.

Toutefois, une interaction potentielle entre le code managé et le mode intégré IIS 7 ou IIS 7.5 peut empêcher les pages .aspx gérées de fonctionner correctement lors de la demande enfant.

J’ai créé ces deux correctifs qui résolvent le problème, utilisez-les non plus.

1) Ajoutez ce code à Global.asax

 void Application_BeginRequest(object sender, EventArgs e) { var app = (HttpApplication)sender; if (app.Context.Request.Url.LocalPath.EndsWith("/")) { app.Context.RewritePath( ssortingng.Concat(app.Context.Request.Url.LocalPath, "default.aspx")); } } 

2) Créer un contrôle de formulaire

 public class FormControlAdapter : ControlAdapter { protected override void Render(System.Web.UI.HtmlTextWriter writer) { base.Render(new RewriteFormHtmlTextWriter(writer)); } public class RewriteFormHtmlTextWriter : HtmlTextWriter { public RewriteFormHtmlTextWriter(HtmlTextWriter writer) : base(writer) { this.InnerWriter = writer.InnerWriter; } public override void WriteAtsortingbute(ssortingng name, ssortingng value, bool fEncode) { if (name.Equals("action") && ssortingng.IsNullOrEmpty(value)) { value = "default.aspx"; } base.WriteAtsortingbute(name, value, fEncode); } } } 

Enregistrez-le en créant ce fichier dans App_Browsers \ Default.browsers

        

Une autre option consiste à vérifier si l’action du formulaire est vide juste avant le rendu de la page. Cela a fonctionné pour moi:

  public void Page_PreRender(object sender, EventArgs e) { if (ssortingng.IsNullOrEmpty(this.Page.Form.Action)) this.Page.Form.Action = "Default.aspx"; } 

Si vous souhaitez append du code supplémentaire dans votre fichier default.aspx, vous pouvez utiliser l’approche similaire définie dans l’article de blog ici ; Il s’agit de redirect l’utilisateur vers la même page par défaut mais avec un nom de page explicite ….

// code, copié du blog mentionné

 protected void Page_Load(object sender, EventArgs e) { ssortingng defaultPage = "default.aspx"; ssortingng rawUrl = Request.RawUrl; //get current url //if current url doesn't contains default page name then add //default page name, and append query ssortingng as it is, if any if (rawUrl.ToLower().IndexOf(defaultPage) < 0) { string newUrl; if (rawUrl.IndexOf("?") >= 0) { // URL contains query ssortingng ssortingng[] urlParts = rawUrl.Split("?".ToCharArray(), 2); newUrl = urlParts[0] + defaultPage + "?" + urlParts[1]; } else { newUrl = (rawUrl.EndsWith("/")) ? rawUrl + defaultPage : rawUrl + "/" + defaultPage; } Response.Redirect(newUrl); } } 

Avez-vous essayé de configurer votre bouton d’image pour utiliser l’événement Command plutôt que «Click»?

Je pense qu’il est possible qu’un clic sur l’image ne provoque pas une publication complète, essayez peut-être de définir les choses comme ci-dessous:

  void ImageButton_Command(object sender, CommandEventArgs e) { if (e.CommandName == "YourCommandName") //do your action } 

Ensuite, définissez votre bouton comme ceci:

   

Je me souviens de devoir le faire pour permettre à un bouton d’image de «soumettre» un formulaire, donc je présume que cela provoquera le postback que vous recherchez.

J’ai déjà eu un problème similaire. Le problème était que dans IIS, le document par défaut était configuré par défaut.aspx, mais le nom de ma page était Default.aspx. C’était juste une question de sensibilité à la casse.

Lorsque j’ai mis à niveau mon projet Web de VS 2005 (.Net 2.5) vers VS2010 (.Net 4.0), VS2010 a inséré ce qui suit dans mon fichier web.config:

        

Lorsque j’ai navigué vers “http: // myserver / mywebsite”, que je pouvais auparavant utiliser sous .Net 2.5, j’ai eu

“Erreur HTTP 500.19 – Erreur de serveur interne” Impossible d’accéder à la page demandée car les données de configuration associées à la page ne sont pas valides. “(Il affiche le nœud” defaultDocument “.)

Cependant, j’ai été en mesure de résoudre le problème très simplement dans web.config en insérant simplement “/” au début de la valeur de la page Web par défaut, comme indiqué ci-dessous:

        

Je n’ai pas eu à faire les autres choses suggérées par les autres répondants.

Y at-il des conséquences imprévues ou des gaffes de le faire de cette façon?

Si votre action de processeur de formulaire n’est pas dans la racine, vous devriez pouvoir utiliser un chemin absolu sans utiliser le nom du fichier.

 

Testé dans .NET 2.0

Le problème est survenu avec le chemin d’action vide, mais a fonctionné correctement avec l’entrée de chemin.

Envisagez d’utiliser des mappages d’URL effectués via votre site web.config. De cette façon, vous pouvez éviter le code supplémentaire dans votre application et laisser IIS fonctionner pour vous.

         

Assurez-vous d’inclure les deux versions de cette URL avec et sans la barre oblique.

Vous pouvez également créer des redirections à partir de dossiers virtuels lorsque vous avez besoin de modifications rapides et que vous ne souhaitez pas modifier le code source (comme indiqué ci-dessus avec l’exemple «this-folder-not-not-exist»).