Good morning,
I have a bit of an odd one I am scratching my head about at the moment, and was wondering if anyone faced something similar in the past. I am working on a rest API in .net6.0, and we have noticed failures on response which are approximately larger than 200MB of JSON (whether an API should return packets this large is a different topic, and we are having discussions about this too).
The main symptom is that the calls come back as a 200, so successful, and I can also see from the API logs that all the processing was completed, however the response body is empty. I can replicate this pointing different clients to the API (e.g. Postman). There is nothing helpful in either the Event Viewer nor the IIS logs.
What I have tried, unsuccessfully:
The API is hosted on a Windows Server 2012 (IIS 8.5) machine, but I also machine to replicate this on a Windows Server 2019 (IIS 10.5) one, so not a compatibility version in terms of IIS version.
Tried adding the following to the web.config file as it resolved a similar thing I had in an older framework:
<httpRuntime maxRequestLength="2147483647" executionTimeout="10800" />
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" />
<!-- maxAllowedContentLength is in bytes -->
</requestFiltering>
</security>
Increased the Response buffering limit in IIS's ASP configuration.
None of those managed to resolve my issue.
One thing I did notice though, is that if I switch the settings to use Kestrel, updating the web.config file to use OutOfProcess, my problem disappears.
While I don't want to use Kestrel, this leads me to believe it's on the IIS front.
Would anyone have seen something like this before and have an idea of what I might be missing? Any advice really appreciated on this one.
Thank you,
Alex.
Related
I'm using Windows 10 Technical preview. I know it's not yet tweeked out to full usage, but here is my problem.
On local IIS I'm developing my web app. It loads most of the data via ASP.NET MVC API. After the upgrade to Windows 10 I started to get
net::ERR_SPDY_PROTOCOL_ERROR
for all AJAX calls to API. The HTML page loads normally, but the dynamic loading of data content fails. I managed to figure it out by starting Chrome with parameters
--use-spdy=off --use-system-ssl
Strange thing is that on the first start I always get this error and have to restart Chrome. Other browsers fail too, but not with specific error. For the transfer there is used HTTP2.0 protocol, which is based on SPDY protocol.
Do I have to turn something off in IIS?
Edit:
Seems like an IIS problem with HTTP2.0. When trying to enter the site from Windows 8.1 I get the same error.
Most people’s reaction to this error would be to reload the web page. We would actually recommend this as a first response. Sometimes this even does work.
Interesting Factoid: SPDY actually stands for “speedy” and is used to reduce a web pages’ load time
If reloading the web pages does not remove the error, then you should close down Google Chrome and restart it. This alone will not really solve the problem because you will need to clear the cache as soon as you restart the browser.
or in cmd clear dns using this command ipconfig/flushdns
Im trying to make connections 4.5 working with content manager. I guess im quite far away from start finally but there are many things i need to fix.
Sometimes my widgets just doesnt load. It says cannot load widgets-config.xml
when i restart deployment and appsrv everything looks good.
My biggest problem is to add library to community. Because i want to see how workflow works and the id like to create linked library of this. This is what i get when i try to add library widget to the community (linked library widget works well)
CLFWZ0004E: Event 'widget.added' sent to remote lifecycle handler at https://conserv.egroup.local/dm/atom/communities/feed returned bad response: 403 - Forbidden
I guess there is som problem with https access. Can anybody of you guys ever faced this problem? Some hints?
UPDATE-1
After accessing that page from it gives me this :
<td:error>
<td:errorCode>UnsupportedOperation</td:errorCode>
<td:errorMessage>CQL5602: The attempted operation, GET, is not allowed on the resource /communities/feed.
Contact your administrator and provide the incident ID: 1381320497551.
The administrator should forward this information to the application owner.
</td:errorMessage>
</td:error>
So i guess maybe there can be som problem with proxy policies. I tried to make some changes with changes default policy url to *. But still no progress..
Hints?
I have a MVC application, in which I am trying to store a image on a network drive and retrieve the same. The application works fine on IE but fails on chrome, upon spending some good amount of time on net I found that this is because of security reasons i.e. Chorme and Firefox prevent retrieving resource from network path and some suggested I have come across was setting UNC path- but even that did not work.
Below are some file path I configured on web.config
<add key="ImageLocation" value="\\user-one\share\UploadImages\" />
UNC Path.
<add key="ImageLocation" value="file\\user-one\share\UploadImages\" />
I would appreciate if someone has come across this issue and have any alternate solution or suggestion to address this.
Regards,
HSR.
I have a strange problem and I just can't figure it out:
I'm including 2 .js files inside of the body. There is nothing else. First one is jQuery (32.4KB) which is downloaded from Google's servers and the second one is also jQuery (same file, 32.4KB) which is downloaded from my server.
And .js file from google is DLed like 5 time faster. And I'm talking just about the "receiving time." Not DNS lookup, connecting, waiting, etc, but plain receiving. I know that Google obviously has good connection but my (i.e. my server's) is not slow by any means - I get like 1MB(megabyte)/sec.
Here is the screenshot of firebug net graph: http://postimage.org/image/42dsog185/
I woudn't be worried if .js file from google would be DLed a bit faster, but 5 times?
Any ideas what could be wrong or how to look deeper into the problem to get the answer?
Thank you, Ed
Google always serves their pages as gzip encoded if your browser supports it, which Firefox does. If your Apache server is not configured with mod_deflate then it will not compress the connection. Is it possible that this is the case?
You should check the headers that your server is sending. If it's not sending:
Content-Encoding: gzip
then that explains the speed difference. Here's a guide to configuring mod_deflate.
I have a Java applet related problem and I would appreciate your help. Here's the story:
I tried creating an applet, that would try to connect to digg.com and by using it's API, show the 100 most popular stories (also include some options to sort and filter the results).
Anyway, the applet opens and shows the GUI just fine in the browser, but when I press the button that loads the news, it won't load them, BUT the news are loaded, when I run the applet in Eclipse.
I thought, that maybe the problem is related to creating the runnable jar from eclipse, since I have some referenced libraries (Google GSON for handling JSON from digg.com). Here are the settings I used for creating the runnable jar (I also tried "Package required libraries into generated JAR):
http://img816.imageshack.us/img816/417/exportjar.png
Here's a picture of the applet (ran from eclipse), when the news have been loaded:
http://img841.imageshack.us/img841/9121/applet.png
I would appreciate any ideas on how to get loading the news to work in the web browser.
I think torah is right. Applets should be able to connect only to their own server. You can try and trick the browser, sending request back to your server asking it to retrieve the data and to return it to applet.
What happens when you attempt to open the connection to digg? Is there a security exception? I wouldn't be surprised to learn that the JVM inside the browser was implementing a same origin policy. If this is the case there should be some kind of Exception (SecurityException I think) being raised when you try to connect to digg.com.
A quick search for "same origin policy java" found the following article which both seems to confirm that this could be your problem.
http://www.zdnet.com/blog/security/defeating-the-same-origin-policy-part-1/946