I have found that IIS 10 is not compressing responses with a 201 status code. Has anyone found a solution for this? This document seems to suggest it was a feature of II 6/7.5:
IIS Troubleshooting
According to the HTTP specification (POST), returning a 201 is incorrect if the body of the response contains the created entity instead of links to it. In this light, the behaviour of IIS is entirely reasonable.
Related
We would like to use PUT, PATCH and DELETE methods when building our internal API in Domino, but I can't configure those methods. Server refusing to pass them.
When I used method PUT Domino replied to me:
Error code: 405 | Request method is not allowed by the server
After that I enabled methods via notes.ini
HTTPEnableMethods=GET,POST,PUT,DELETE,HEAD,PATCH
That seems to help a bit but now it says something about URL, but I do not really get what it means.
Error code: 405 | The HTTP method is not allowed for the specified URL
I have made tests on two different setups: with and without internet sites documents enabled in server documents.
Does anybody what I need to do to solve the problem above?
UPDATE
I just noticed a help text on Internet Site for "Methods" field.
GET, HEAD, and POST are the most commonly used methods. OPTIONS and TRACE are useful for debugging. PUT and DELETE should only be enabled if the Web site includes special CGI programs or Java applications that implement them.
Based on that it seems it is not possible to make PUT and DELETE work out of the box.
Most of the site sources, opens with a simple request, usualy by file_gets_contents() or curl_init().
I've tried a lot of combinations of stream_context_create() and curl_setopt(), and none returned any thing different of 400 bad request.
Is there an explanation for why some server-sites ( like https://phys.org/ ) do not return de source code by quoted methods?
obs.: if you were able to get the source of the exemple ( https://phys.org/ ), using file_gets_contents() or curl_init(), or any other method with php, please post the code, thanks.
Some Website's are validating the request if it comes from a real/allowed client (bot/user).
This can have multiple reasons.
Maybe the bots are sending to many requests, or the specific site is blocked behind a paywall/firewall. But there are many other people who can explain it to you better then me.
Here are some known Examples how they did it:
Some Site's are supporting request with an API-Token.
Google API's are an great example.
Some Site's are validing the User-Agent.
It looks like that your example site is doing this.
When I'm sending a custom User-Agent Header the result is returning to an error.
And Of Course can some site's check for the User IP Address :)
I believe in your example there should be a good solution to get a result.
Servicestack Version: 3.9.71.0
Target Framework: .NET 3.5
Program background: has been in production use for over 3.5 years
Recently due to a customer security audit items were brought to our attention. All but one have been eliminated as IIS configuration changes.
The last item identified describes a situation in which the probing software accessed an endpoint without the proper authentication. This was fine and the expected result was the 403 Forbidden. The unexpected result was that the response body is displaying certain internal information of the server.
Based on quite a few articles I have searched it seams the the response body information being returned is a result of how Servicestack my be configured.
I realize this is a fairly older version of Service Stack. My preference would be to identify an IIS setting to override a forbidden response. Aside from that an option to just return a status code of 403 without the additional information. The third would be to create and use a custom 403 response object to control what is revealed.
Any guidance or help would surely be appreciated.. Thank you in advance.
ServiceStack v3 is a very old version of ServiceStack last updated in 2013. If you need to make any changes you'll need to create a custom build from its Sources
Looking at the v3 sources for how it resolves the ForbiddenHttpHandler:
ForbiddenHttpHandler = config.GetCustomErrorHttpHandler(HttpStatusCode.Forbidden);
It looks like you'll be able to override what HttpHandler is used by overriding the CustomHttpHandlers, e.g:
EndpointHostConfig.Instance.CustomHttpHandlers[HttpStatusCode.Forbidden] = MyHandler {...}
I have searched all over the internet for an answer and although I can find a million people with the same question I cannot find an official solution to the problem im experiencing.
I always get "Cannot display preview. You can post as is, or try another link." displayed.
I've stripped a page down to only the required open graph meta tags so I know they work (run through multiple OG validators), Ive disabled any kind of robots blocking, any kind of redirects, disabled the firewall on a test server, made sure the LinkedIn bot requests are hitting the server. All I see in the browser console all the time is a status 500 being returned from LinkedIn's preview generator API.
We are hosting on Windows Server in IIS 8.5, it seems if I create a demo and host it somewhere else it works, which makes me think it is server related or IIS settings.
Reading this Linkedin post's picture doesn't appear in summary its seems like a similar issue. We are not serving over SSL so nothing to do with that.
I have already asked this question on LinkedIn's forum but having no luck, so im hoping someone on here can help or someone from LinkedIn's tech team can help.
Thanks
So we had this issue as well and it turns out parts of our system that use user generated themes were not adding the "Content-Type" header to the response.
So examine the response headers coming from your server and make absolutely sure they are correct and that they include the correct "Content-Type" (with correct encoding) and "Content-Length".
I have been trying to insert a RSS Viewer web part in my SP 2010 site however i receive the error:
ProtocolError occured trying to complete the request. The server returned a status code of : ProxyAuthenticationRequired and the status description is : "Proxy Authentication Required"
This seems to only happen when a feed does not end in ".rss". I have tried external and internal Sharepoint sites and MSDN feeds and they all work fine.
Is there anything i can do to fix this?
Thanks in advance
This is a bit of longshot but permission might be given to have the .rss mime type to be handled by your webserver. Maybe you can have a look there. If there is a handler for the .rss type. Maybe you can copy that for the extension you do want.
See here: http://www.dotnetperls.com/ashx
and here: http://technet.microsoft.com/en-us/library/cc771240%28WS.10%29.aspx
Are you making sure you are sending the correct mime type with your request/response?
Try using wireshark or fiddler to inspect the network traffic. Sometimes there is some negotiating in network packets which can give vital information.