We have a internal NuGet server (ASP.net app using the NuGet.Server package) and we want to use it with Octopus to deploy packages. So the first thing you hit is that the packages are too large.
When you push a package larger than around 7 Meg you get:
Failed to process request. 'Request Entity Too Large'.
The remote server returned an error: (413) Request Entity Too Large..
Based on the documentation on Octopus, I updated the web.config file to have the changes.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="elmah">
<section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah"/>
<section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah"/>
<section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah"/>
<section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah"/>
</sectionGroup>
</configSections>
<system.web>
<compilation debug="true" targetFramework="4.0"/>
<httpModules>
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah"/>
</httpModules>
<httpRuntime maxRequestLength="419430400" executionTimeout="3600"/>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true">
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" preCondition="managedHandler"/>
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah" preCondition="managedHandler"/>
<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah" preCondition="managedHandler"/>
</modules>
<staticContent>
<mimeMap fileExtension=".nupkg" mimeType="application/zip"/>
</staticContent>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="419430400"/>
</requestFiltering>
</security>
</system.webServer>
<elmah>
<security allowRemoteAccess="false"/>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data"/>
</elmah>
<location path="elmah.axd" inheritInChildApplications="false">
<system.web>
<httpHandlers>
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/>
</httpHandlers>
</system.web>
<system.webServer>
<handlers>
<add name="ELMAH" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" preCondition="integratedMode"/>
</handlers>
</system.webServer>
</location>
<appSettings>
<add key="apiKey" value="KeyHere"/>
<add key="packagesPath" value=""/>
</appSettings>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
</configuration>
That does not work. Other posts talk about running something like (IIS7):
appcmd.exe set config -section:system.webServer/serverRuntime /uploadReadAheadSize:"419430400" /commit:apphost
or (IIS6):
cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 419430400
I tried both to no avail. Neither command returned an error, so I assume that the value '419430400' is correct for all of the calls (bytes vs. some other unit of size).
Anyone have any idea what I am missing?
I ended up just copying the package to a share on the web server, but I would really like the push command to work.
Not exactly answering the OP's question, but related to the topic, I was getting the (413) Request Entity Too Large error while using NuGet push to push to a local SymbolSource server - turned out I was submitting to a slightly incorrect URL, once I corrected the command to point to the base /NuGet/ URL, it ran just fine.
No idea why an incorrect URL results in the 413 error, but there you go. Hope this helps someone.
EDIT: based on comments below, you may have more luck just referencing the base http://www.myserver.com/ URL rather than including the /NuGet as well. Worth playing around a bit.
I know this is an old question, but today I was faced with the same error. It's worth noticing that I'm using TeamCity package building and publishing. Anyway, when I try to Publish my huge package (about 200 MB) I was blocked with this. The solution was simple:
Instead of publishing to http://mynugetserver/api/v2/, use: http://mynugetserver/
You'll have to set these guys to higher values:
system.web - httpRuntime - maxRequestLength to, say, 1048576
system.webserver - security - requestFiltering - requestLimits -
maxAllowedContentLength to, say 1073741824
Both values are in a different unit so the second one should be larger than the first.
Also, have a look at www.myget.org which I found great when working with Octopus Deploy.
Check your serverRuntime configuration.
The maxRequestEntityAllowed and uploadReadAheadSize attributes respectively configure limits for the maximum number of bytes allowed in the entity body of a request and the number of bytes a Web server will read into a buffer and pass to an ISAPI extension.
More details: http://www.iis.net/configreference/system.webserver/serverruntime
My guess is that you are using SSL and setting uploadReadAheadSize will solve the issue. Because during client renegotiation process,the request entity body must be preloaded using SSL preload. SSL preload will use the value of the uploadReadAheadSize property, which is used for ISAPI extensions.
Here are the defaults
<location path="Default Web Site">
<system.webServer>
<serverRuntime enabled="true"
uploadReadAheadSize="49152"
maxRequestEntityAllowed="4294967295" />
</system.webServer>
</location>
Based on #Keith and #Nubigetter's answers, I did some further research, because the behavior seemed really weird to me.
The answer is actually in the documentation for Nuget.Server (if you look very carefully), it's just not very obvious:
use http://mynugetserver/nuget for list/restore
use http://mynugetserver/ for push
I've raised this with the Nuget team here https://github.com/NuGet/NuGetGallery/issues/2903 because I regard this behavior as 'presenting opportunity for improvement'.
This is due to nginx limitations, the nuget server in Linux system use nginx as proxy and config file under:
/etc/nginx/conf.d/nuget.conf
server_name localhost;
root /var/www/public/;
client_max_body_size 200M;
change client_max_body_size 200M is working for me.
I had the same issue:
[Step 1/2] Publishing package to feed at http://localhost/OctopusDeploy/nuget/packages...
[Step 1/2] Failed to push to package feed at 'http://localhost/OctopusDeploy/nuget/packages/'.
[Step 1/2] (The server responded with: [413] Request Entity Too Large)
[Step 1/2] Process exited with code 1
but the Octopus Deploy service had stopped!
What worked for me was in this article:
http://blogs.blackmarble.co.uk/blogs/rfennell/post/2012/10/31/403-and-413-errors-when-publishing-to-a-local-Nuget-Server.aspx
"Important: This second error was a red herring, you don't need the /nuget on the end of the URL"
Related
As title, I want to disable Anonymous Authentication for my ASP.NET Boilerplate web site (MVC) in IIS Server and use Form Authentication instead. Is it possible to do this because if I disable Anonymous Authentication, my website cause an error "HTTP Error 404.15 - Not Found"
Update 1: Here is my web.config
<system.web>
<globalization culture="auto" uiCulture="auto" />
<compilation debug="true" targetFramework="4.6.1">
<assemblies>
<add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
<httpRuntime targetFramework="4.5.1" />
<customErrors mode="Off">
<error statusCode="404" redirect="~/Error/E404" />
</customErrors>
<httpHandlers>
<add path="Reserved.ReportViewerWebControl.axd" verb="*" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" validate="false" />
</httpHandlers>
<authentication mode="Forms" />
</system.web>
I still remember the first time I had to implement Forms Authentication in ASP. All I can say is there is a reason I only do linux based web-development now!
It is a real pain, but this should work if you don't intend on using a database to manage the users.
If you do intend to use a database then prepare yourself for a long road. U need to have the correct MSSQL database for the correct Visual studio tool and they also removed the management interface completely so you either have to design your own or use a tool that is available on the internet somewhere. I still remember I got so frustrated by the whole idea of it, that I literally wrote my own management tool I could deploy on developed sites. If it wasn't on a broken harddrive I would give it to you.
<authentication mode="Forms">
<forms loginUrl="login.aspx" defaultUrl="welcome.aspx">
<credentials passwordFormat="Clear">
<user name="abhishek" password="abhi#123"/>
<user name="Kantesh" password="sinha#123" />
</credentials>
</forms>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
If you plan on using a database to store your users google some tutorials.
The reason why you are getting a 404 is because you are not specifying loginUrl or it is incorrect and pointing to a non-existant page.
Hope this helps
When you disable anonymous access to all pages you cannot let users to see login page as well. what you need to to do is allowing some specific pages like login or register to be accessible.
This might not completely fits for you but you get the idea.
If it doesn't work, try removing the backslash "/" for the "/account/login" and set it like "account/login"
<configuration>
<system.web>
<authentication mode="Forms" />
<authorization>
<deny users="?" /> //this will restrict anonymous user access
</authorization>
</system.web>
<location path="/account/login"> //path here is path to login page
<system.web><authorization><allow users="*" /> // this will allow access to everyone to login page
</authorization></system.web></location>
</configuration>
BaseLine: ServiceStack sample works for me in a stock MVC 4 app. I am using the variant, followed all the instructions in the readme, no problems.
Plugin Framework
I am building a plugin framework for MVC and servicestack.net is one of the plugins, that being all the assemblies are plugins which get loaded, using BuildManager.AddReferencedAssembly(assembly);
BuildManager.AddCompilationDependency(assembly.FullName);
All the ServiceStack dlls are found and successfully loaded from my personal shawdowFolder.
webconfig:
<location path="api">
<system.web>
<httpHandlers>
<add path="*" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory,ServiceStack" verb="*" />
</httpHandlers>
</system.web>
<!-- Required for IIS 7.0 -->
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<add path="*" name="ServiceStack.Factory" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory,ServiceStack" verb="*" preCondition="integratedMode" resourceType="Unspecified" allowPathInfo="true" />
</handlers>
</system.webServer>
</location>
*NOTE: I am calling from Application_Start AppHost.Init(), and I can step it so ServiceStack is truly loaded and usable before the ASP.NET app goes into full swing.*
On first launch: /api/metadata results in:
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /api/metadata
Stopping the debugger and simply relaunching, which deletes all assemblies from my personal shawdowFolder, copies them, loads them, references them, results in.
A working ServiceStack.net
StarterTemplate ASP.NET Host
The following operations are supported. For a formal definition, please review the Service XSD.
etc.
I suspect that this problable has to do with .NET's shadowfolder and appdomain, but perhaps it is something with ServiceStack. Where would I find logs to see if ServiceStacks httphanderfactory is having problems.
I Changed my config as follows :
SetConfig(new EndpointHostConfig
{ ServiceStackHandlerFactoryPath = "ss"}
and my config :
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add type="DevExpress.Web.ASPxClasses.ASPxHttpHandlerModule, DevExpress.Web.v13.1, Version=13.1.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" name="ASPxHttpHandlerModule" />
<add name="FormsAuthenticationDisposition" type="ServiceStack.ServiceInterface.SuppressFormsAuthenticationRedirectModule, ServiceStack.ServiceInterface" />
</modules>
<handlers>
<add type="DevExpress.Web.ASPxUploadControl.ASPxUploadProgressHttpHandler, DevExpress.Web.v13.1, Version=13.1.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET,POST" path="ASPxUploadProgressHandlerPage.ashx" name="ASPxUploadProgressHandler" preCondition="integratedMode" />
<add type="DevExpress.Web.ASPxClasses.ASPxHttpHandlerModule, DevExpress.Web.v13.1, Version=13.1.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET" path="DX.ashx" name="ASPxHttpHandlerModule" preCondition="integratedMode" />
<add path="ss*" name="ServiceStack.Factory" type="ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack" verb="*" preCondition="integratedMode" resourceType="Unspecified" allowPathInfo="true" /></handlers>
<validation validateIntegratedModeConfiguration="false" />
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="30000000" />
</requestFiltering>
</security>
</system.webServer>
Now I have to type in the following to get to my servicestack area : http://localhost/ss/
My take on what is going wrong is that mvc/asp.net forms/ servicestack each needs one entry point to map its handler to an url route, servicestack is overriding the url route for "/" your MVC project hence no resources is found.
Thus in my application I used to seperate entries points:
*http://localhost/* .... is my normal entrypoint for webforms (in your case MVC4[stock])
http://localhost/ss .... is my servicesstack entrypoint
If you are using the MVC razor engine you won't run into this.
While developing a ASP.NET MVC4 web application with VS2010, using the Mvc.JQuery.Datatables Nuget,
I found that the EmbeddedResourceVirtualPathProvider NuGet that is referenced, worked beautifully
on my dev box, but failed miserably on my production box.
The production box is Windows 2003, with IIS6 and .NET 4.0 installed.
I searched many things on SO, and Googling, but after implementing the suggested workarounds,
it still fails:
Here's what I've done.
Implement AppInitialize as suggested by https://stackoverflow.com/a/5178993
Implemented Wildcard mapping for ASP.NET as suggested by http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Implemented IgnoreRoute for static files as suggested by https://stackoverflow.com/a/3144841
but it still doesn't serve all of the files. I'm getting the embedded partial views, but not
the embedded css, js, and jpg files.
My web.config has an entry for the StaticFileHandler as follows:
<system.webServer>
<handlers>
<add path="*.css" verb="GET" name="Static css" type="System.Web.StaticFileHandler" />
<add path="*.js" verb="GET" name="Static js" type="System.Web.StaticFileHandler" />
<add path="*.jpg" verb="GET" name="Static jpg" type="System.Web.StaticFileHandler" />
<add path="*.gif" verb="GET" name="Static gif" type="System.Web.StaticFileHandler" />
</handlers>
</system.WebServer>
I appear to be missing something critical. Any Suggestions?
When using IIS6, all of the items listed in #1-3 are required, but additionally, you need to
recognize that IIS6 defines its handlers as httpHandlers in the system.web section,
whereas IIS7 calls them handlers and they are in the system.webServer section of the config file.
Therefore, you need to add the following to make it work in IIS6
<system.web>
....
<httpHandlers>
<add path="*.css" verb="GET" type="System.Web.StaticFileHandler" />
<add path="*.js" verb="GET" type="System.Web.StaticFileHandler" />
<add path="*.jpg" verb="GET" type="System.Web.StaticFileHandler" />
<add path="*.gif" verb="GET" type="System.Web.StaticFileHandler" />
</httpHandlers>
</system.web>
I have a very strange issue. I am not able to run a windows azure application which has a WCF service and mschart in it.
Following are the steps to reproduce the error:
1) Create a new windowsazureapplication with a blank asp.net webrole
2) Now add a new WCfService
3) run to check it runs ok
4) now in one of the pages include mschart, and open the design of the page to make sure the webconfig is changed to use the mschart.
5) now try to run the project.
I am getting error message like this one:
Is this a problem with windows azure or am I doing somthing wrong?
FYI: This is not my first project on windows azure.
I think I have found the solution. You just need to add the following in your web.config inside system.webserver section:
<validation validateIntegratedModeConfiguration="false"/>
The final system.webserver looks like as below:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="ChartImageHandler" />
<add name="ChartImageHandler" preCondition="integratedMode" verb="GET,HEAD,POST"
path="ChartImg.axd" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</handlers>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
After adding above, I did not see the problem at all.
I've got an existing web application, that is installed on several machines. script clients and .net clients consume ".asmx" services through one machine, that routes all calls to other machines.
Client ----> |Website \ Virtual directory(HttpHandler)| ----> |Other server \ real .asmx|
I added a new .svc service that does the same functionality, and added a handler for it (directory's config):
<system.webServer>
<handlers>
<add name="MY_ASMX" verb="*" path="*.asmx" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
<add name="MY_ASPX" verb="*" path="*.aspx" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
<add name="MY_WSDL" verb="*" path="*.wsdl" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
<add name="MY_SVC" verb="*" path="*.svc" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
while asmx request are routed fine, my new .svc on the end server does not get called, and even the Httphandler is skipped. if i call the .svc directly on the other machine it works.
the error i get is:
WebHost failed to process a request.
Sender Information: System.ServiceModel.Activation.HostedHttpRequestAsyncResult/26458746
Exception: System.Web.HttpException (0x80004005): The service '/Mysite/MyDirectory/settings.svc' does not exist. ---> System.ServiceModel.EndpointNotFoundException: The service '/Mysite/MyDirectory/settings.svc' does not exist.
I already tried the folowing
add "buildProviders" to compilation section that removes .svc
Click on MimeTypes and enter “.svc” and “application/octet-stream” and save
add a handler :
nothing helps, http handler is not being called
p.s. Im working with AppPool .net 4.0 Integrated
.svc extensions are considered by default to be WCF services, and handlers/modules are already present for them. You can remove the existing handlers/modules by putting a element before your <add> element:
<remove name="svc-ISAPI-4.0_32bit" />
(or, if on win64:)
<remove name="svc-ISAPI-4.0_64bit" />
And, in the <modules> element:
<remove name="ServiceModel-4.0" />
I've found it. Adding:
<compilation debug="true" >
<buildProviders>
<remove extension=".svc"/>
</buildProviders>
</compilation>
caused an error, that got me to back off, at the first time:
"~/ServiceManagement.svc" demanded that the buildProvider for ".svc" will be on
"~/ServiceManagement.svc" is automatiacally created in the machine root config when you install MS AppFabric. Since I'm using that folder only for redirection, I don't need Appfabric there, so I removed it:
<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<remove relativeAddress="~/ServiceManagement.svc"/>
</serviceActivations>
</serviceHostingEnvironment>