Content-Range header IThitWebDav server - webdav

I have installed ITHIT webdav server engine. I tried using CalDev and Class1 server engine instances.
However, I was not successful with enabling content-range header.
When I am sending PUT with content-range header includes, the IIS server is responding with 501 not implemented.
Kindly help in resolving content-range header issue.

Typically CalDAV clients do not send PUT with Content-Range. The sample CalDAV implementation, generated by CalDAV/CardDAV Web Application wizard for Visual Studio does not implement resumable upload.
If you really need resumable upload in CalDAV/CardDAV server, you can modify the IContent.Write method implementation. This method provides necessary parameters to process segmented uploads. By default you can find the Write method in CalendarFile.cs file.

Related

How to generate a tomcat CSRF nonce?

I want to automate requests to Apache tomcat's manager GUI for the purposes of developing a pentest related application. I captured the packet to upload a .war file to the server and this was the first part of the response:
POST /manager/html/upload?org.apache.catalina.filters.CSRF_NONCE=0DCEAA88E8C558E6F3352C52B4BBCD4B HTTP/1.1
From this I can see that there's some kind of nonce preventing cross site request forgery. The problem is that I want to automate sending these packets to the server, so I'm going to need to generate a valid nonce whenever I do that. Is there a way I can grab the current nonce so I can use it in my script?

How the server really handle the response to a http request?

I understand that the server send website components to the client after http request, HTML, CSS, Js and other static files that are necessary to build the website in the client browser.
I want to understand what the server actually do to generate the response since it should handle many requests not just one request??
I assume that the server create an instance from the files and send it to the client via http response?? is this right, wrong,inaccurate or incomplete or are there other processes that happen on the server to make it work??
These "website components" (code for the browser) can be created by the server however it wants. There are two typical patterns. Static and dynamic.
Static resources are created ahead of time. These cannot be customised by the server at the time of the request.
Dynamic resources will be generated when the request is received. For example, a HTML asset may be generated to include a particular user's username as found in a cookie sent with the request. This is typically done from templates like jinja2 for Python.
Nowadays serving these resources statically and using a client side JavaScript application with a separate data API to customise content is the most popular way to build interactive websites (web apps)

IIS does not seem to be compressing response created by ashx

I have an ashx handler, and the response is not gzipped. The content-encoding received by the client is empty.
The IIS settings for the site have static and dynamic compression enabled.
Research of similar problems shows some people have an httpCompression node in the web server node of IIS configuration editor. I do not have such a node. I have a url compression node, where I have set everything to true. Perhaps that is IIS version dependent. The op system is Windows Server 2008 R2.
I am about to try to "force" compression using the filter property and the GZipstream class (credit to Rick Strahl's blog). If anyone can tell my why IIS is not "auto compressing" or can point to any gotchas in my workaround I would be grateful.
Update: attaching GzipStream to the response filter reduced the content length by half as seen by the client, which seems to indicate the "manual" compression is doing something.
I am aware this was previously asked here:
.ashx handler not getting gzip compressed despite IIS Config setting
However, the previous question did not receive any answers, so I am asking the question again.
Please check if you are adding Accept-Encoding", "gzip" in request headers while making HTTP request.

IIS Dynamic Compression Failing

I'm trying to get Dynamic Compression on IIS 8.5 to work (particularly with JSON). I'm using Windows Server 2012, IIS 8.5 and a very simple ASP.NET MVC site returning an ActionResult in the form of JSON. Firstly I have done all the usual steps, enabling Dynamic Compression in IIS at the server and site level, edited my applicationHost.config with the correct MIME types, frequency etc.
I have enabled FailedRequestTrace logging, and what is strange is that my request is reporting a successful compression, however Chrome/Fiddlr disagree:
And the response in Trace logging contains the header "Content-Encoding: gzip":
But the response in Chrome/IE/Fiddlr does not contain that header nor is the response compressed, it would appear that something else is interfering! Please help!
If the server is serving the response zipped (use WireShark to determine this) but you are seeing the response deflated in the browser it's likely to be your antivirus unzipping before the content gets to your browser
WireShark

find which server in a web farm the web method got executed?

This question is a consequence of the following question: determining which server (in a web farm) the asp.net ajax request came from?
The problem is that we commonly use automatically generated proxy classes to communicate with the web method (which may be part of asmx/wcf service). When we receive the response from the web services server, how do we know which server it got processed from?
We receive the response from the server side code which is executing (mostly). When its a script service (which can be called via javascript) its another case altogether.
How can we read the response headers once the web service returns?
Am I constrained to build my own proxy classes to solve this problem?
One way. Its not the best way but it will do until something new comes about. If you have a tool like fiddler/burp, you can inspect the response headers. So we must configure the IIS to set the response headers appropriately.
By default they are configured to output something like X-ASP.NET...a good idea would be to add the server name to that...

Resources