Skip to main content

ASP.NET e IIS – Errore (413) Request Entity Too Large e Maximum Request Length Exceeded – Come risolvere

Se vi siete imbattuti in questo articolo è probabile che stiate cercando di configurare la vostra applicazione ASP.NET (Core, MVC, Web API, Windows Forms, WCF o altro) su un web server IIS il quale, a differenza del web server di sviluppo, si rifiuta di accettare l’upload di un file di dimensioni superiori a 16kb, restituendo uno dei seguenti errori:

(413) Request Entity Too Large

Entità richiesta troppo grande

Maximum request length exceeded

Superata la lunghezza massima della richiesta

Tutti questi errori sono relativi al superamento delle dimensioni massime di un allegato – o meglio, della Request HTTP inviata al server – previste dalla nostra applicazione ASP.NET per impostazione predefinita. Queste limitazioni sono state inserite per una valida ragione: la ricezione di un file è una operazione piuttosto pesante per il server, in quanto impegna a tempo indeterminato un working thread. Per questo motivo, le impostazioni predefinite della maggior parte delle applicazioni ASP.NET prevedono una dimensione generalmente compresa tra i 16k e i 64k, sufficiente per l’invio/ricezione di form di testo ma logicamente del tutto inadeguate quando si ha l’esigenza di gestire l’upload di uno o più file.

(altro…)

 

Estensione Url.Action in C# per gestire Route multi-language con ASP.NET MVC

Come promesso in questa guida – e richiesto a gran voce dai nostri lettori – pubblichiamo un Extension Method che consente di utilizzare il metodo helper Url.Action all’interno di una View in Razor specificando, in aggiunta ai consueti parametri, un oggetto CultureInfo che verrà utilizzato internamente per costruire una URL localizzata. Ovviamente, affinché la URL venga correttamente gestita dalla nostra applicazione, sarà necessario implementare una Route con supporto multi-language come quella pubblicata in questo post.

(altro…)

 

Estensione Html.ActionLink in C# per gestire Route multi-language con ASP.NET MVC

Come promesso in questa guida – e richiesto a gran voce dai nostri lettori – pubblichiamo un Extension Method che consente di utilizzare il metodo helper Html.ActionLink all’interno di una View in Razor specificando, in aggiunta ai consueti parametri, un oggetto CultureInfo che verrà utilizzato internamente per costruire la URL localizzata dell’ActionLink che verrà restituito. Ovviamente, affinché la URL venga correttamente gestita dalla nostra applicazione, sarà necessario implementare una Route con supporto multi-language come quella pubblicata in questo post.

(altro…)

 

Impostare un sito web multi-language con ASP.NET MVC

Premessa

Fin dal giorno della sua prima release il .NET Framework dà la possibilità agli sviluppatori di impostare un qualsiasi progetto – sia esso un Website, una Web Application, un client realizzato con Windows Forms o con il più recente approccio WPF/XAML o altro – in modalità multi-language, ovvero con supporto di localization multiple, mediante l’utilizzo dei cosiddetti Resource Files, contraddistinti dall’estensione .resx. Non è intenzione di questo articolo spiegare l’utilizzo dei Resource Files, per i quali rimandiamo all’ottimo walkthrough ufficiale presente sul sito Microsoft: ci limiteremo a ricordare che, come probabilmente già saprete, lo scopo dei Resource Files è quello di immagazzinare in un array di chiavi/valori una serie di elementi di testo e/o immagini per ciascuna lingua supportata dall’applicazione: per ottenere questo risultato lo sviluppatore non deve far altro che creare un Resource File per la lingua predefinita (ad es. l’inglese) e poi un Resource File per ciascuna lingua, utilizzando lo stesso nome del file originario con l’aggiunta del codice ISO 639-1 (two-letters language code) e, se necessario, il codice ISO 3166-1 (two-letters country code) ad essa relativi. Sarà quindi possibile, ad esempio, creare:

  • un Global.resx per immagazzinare i testi nella lingua predefinita
  • un Global.it.resx contenente le medesime chiavi con i testi tradotti in lingua italiana
  • un Global.de.resx contenente le medesime chiavi con i testi tradotti in lingua tedesca

e così via. Una volta fatto questo, sarà sufficiente utilizzare le chiavi impostate in questi file in luogo dei testi veri e propri (per sapere come, leggete il walkthrough di cui sopra): il Framework .NET penserà automaticamente a cercare la chiave nei vari Resource File, partendo da quello con l’estensione più vicina alla Localization impostata sul thread corrente e procedendo a ritroso fino a quello relativo alla lingua predefinita.

A conti fatti, si tratta di una funzionalità davvero niente male. Vediamo come utilizzarla per rendere multi-language una Web Application basata su ASP.NET MVC.

(altro…)

 

HTTP Basic Authentication con ASP.NET MVC tramite ActionFilter

Nello sviluppo di una applicazione ASP.NET MVC è possibile che prima o poi ci si trovi nella necessità di restringere l’accesso ad una o più risorse web. Se la nostra applicazione prevede un sistema di autenticazione di qualsivoglia tipo (come ad esempio ASP.NET Membership Provider o il più recente ASP.NET Identity) è possibile sfruttare il sistema di utenti e ruoli predefinito per restringere l’accesso alle risorse che vogliamo tramite l’utilizzo dell’attributo AuthorizeAttribute presente nel namespace System.Web.Mvc a livello di Controller o di singolo ActionResult:

Questo approccio richiede però necessariamente che l’utente effettui un login ed è quindi poco indicato qualora si voglia mettere in piedi un WebService o una interfaccia RESTful di qualsivoglia tipo. Per queste situazioni specifiche è probabilmente più indicato uno dei meccanismi di autenticazione previsti dal protocollo HTTP: Basic, Digest, NTLM solo per citarne alcuni. Il più diffuso, nonché il più semplice da supportare in ambiente MVC, è senza dubbio il meccanismo di Basic Authentication, per implementare il quale è sufficiente aggiungere al proprio progetto il seguente attributo ActionFilter personalizzato:

Come si può vedere il filtro controlla la presenza del campo Authorization negli header della Http Request e agisce di conseguenza:

  • Se presente, confronta l’username e la password presenti nella richiesta con quelle previste dal sistema.
  • Se non presente, produce un Http Response di tipo 401 per avvisare il client che per accedere alla risorsa richiesta è necessario l’inserimento di apposite credenziali. Questo tipo di risposta produrrà, nella maggior parte dei browser web, la classica finestra pop-up di inserimento di username e password.

L’implementazione mostrata prevede delle credenziali inserite ad-hoc, ma può essere agevolmente estesa per far sì che l’ActionFilter utilizzi un qualsivoglia sistema di autenticazione personalizzato (MembershipProvider, ASP.NET Identity, base utenti personalizzata su DB esterno o su file, etc.) semplicemente eliminando il costruttore personalizzato e modificando il contenuto del blocco IF presente nell’override del metodo OnActionExecuting.

Il principale vantaggio di gestire la Basic Authentication in questo modo è che l’ ActionFilter così creato può essere utilizzato sia a livello di Controller che di singolo ActionResult, proprio come l’attributo Authorize menzionato sopra: