When attempting to upload any number of documents, including very small files, seems to succeed- but subsequently redirects to an error page indicating the following:
/_layouts/error.aspx?ErrorText=The%20HTTP%20verb%20POST%20used%20to%20access%20path%20%27%2F%5Fvti%5Fbin%2Fshtml%2Edll%2FSiteCollectionDocuments%2FForms%2FUpload%2Easpx%27%20is%20not%20allowed%2E
The HTTP verb POST used to access path '/_vti_bin/shtml.dll/SiteCollectionDocuments/Forms/Upload.aspx' is not allowed.
Any ideas as to why HTTP POST would be denied for this operation?
Update:
Navigating directly to /_vti_bin/shtml.dll/SiteCollectionDocuments/Forms/Upload.aspx gives:
The XML page cannot be displayed
Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.
An invalid character was found in text content. Error processing resource 'http://sitename/...
MZ
Error in event log looks like this:
Critical error has occured but the exception object has already been cleared
Current Url: /_vti_bin/shtml.dll/SiteCollectionDocuments/Forms/Upload.aspx
User Login: xxxxxxx
User is Authenticated: True
Performance Counters
% Processor Time Total: 0
Processor Queue Length: 1
ASP.NET Request Queued Total: 1
.NET CLR Exceptions, # of Exceps Thrown: 55
PATH_INFO: /_vti_bin/shtml.dll/SiteCollectionDocuments/Forms/Upload.aspx
PATH_TRANSLATED: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\isapi\shtml.dll
The solution turned out to be removing the wildcard application mapping in IIS.
The url which receives the document upload via HTTP POST /_vti_bin/shtml.dll/SiteCollectionDocuments/Forms/Upload.aspx was being incorrectly mapped to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll and thus failing.
Update:
This solution tended to break other functionality, such as document deletion, and was scrapped during testing.
As it turns out, there was an HTTP module that was causing this url to be processed incorrectly. I added a bypass for /_vti_bin/shtml.dll/SiteCollectionDocuments/Forms/Upload.aspx and this solved the issue with no side effects.
The supported methods of uploading documents to SharePoint are:
Using web services (extensive example here)
Using RPC (example here)
Using the object model (example here)
Are you able to use one of these methods? If not can you please edit your question with more information about why and some sample code?
A guess at why the HTTP POST method isn't working is probably because it's for internal SharePoint use only.
Related
I set up my own hosted phabricator, everything is working fine (Diffusion repo etc)
I ran into problem after I installed arcanist on my dev box and run 'arc install-certificate', got exception as following:
rying to connect to server...
LOGIN TO PHABRICATOR
Open this page in your browser and login to Phabricator if necessary:
http:///conduit/login/
Then paste the API Token on that page below.
Paste API Token from that page: cli-e644viducdcccrge4i7zo5nfa66d
Usage Exception: The token "cli-e644viducdcccrge4i7zo5nfa66d" is not a valid API Token. The server returned this response when trying to use it as a token: ERR-CONDUIT-CORE: Attempting to access attached data on PhabricatorUser (via getAwayUntil()), but the data is not actually attached. Before accessing attachable data on an object, you must load and attach it.
I am wondering what's might go wrong? Thank you very much for your insights!
I've seen this problem occur many times with our users. In every case so far, the problem has been that users have set up the phabricator uri incorrectly.
Suggestion:
Check your project .arcconfig or your global .arcrc files (if you're doing this outside a project).
Verify that the URI to your Phabricator site is correct. The typical issue I've seen is accessing using http:// rather than https://
I've got a bit of an odd situation that recently came up in a security scan and I'm having trouble explaining it. In short, the following URL always returns HTTP 400 and a YSOD:
http://www.mypal4me.com/C:badfile
This site is ASP.NET 4 and is hosted on MaximumASP under IIS7.5. This site is configured with custom errors turned ON and a default redirect page. This is evidenced by causing request validation to throw you off to the error page: http://www.mypal4me.com/?%3Cscript%3E
The only way we've found to send this request off to the custom error page is to add an <error statusCode="400" path="/error.htm" responseMode="ExecuteURL" /> entry under system.webServer.httpErrors in the web.config (obviously this hasn't been done on the site above but has on other MaximumASP sites).
So my question is twofold:
Why is this request not being caught by the usual .NET error handling and the custom error page served as a result?
Why do I only see this happen at MaximumASP - I can't reproduce an HTTP 400 with that pattern in any other IIS/ASP.NET environment.
http://msdn.microsoft.com/en-us/library/s57a598e.aspx
ASP.NET 4 also enables you to configure the characters that are used
by the URL character check. When ASP.NET finds an invalid character in
the path portion of a URL, it rejects the request and issues an HTTP
400 (Bad request) status code. In previous versions of ASP.NET, the
URL character checks were limited to a fixed set of characters. In
ASP.NET 4, you can customize the set of valid characters using the new
requestPathInvalidChars attribute of the httpRuntime configuration
element, as shown in the following example:
It's likely request filtering, specially it doesn't like the C: bit, fearing that it is a directory travesal attack of some sort. Many webhosts security settings will block suck a url.
A most likely guess at the the product in use is UrlScan, http://learn.iis.net/page.aspx/473/using-urlscan
Because this filtering runs at a much lower level in the call chain, the request itself is never passed to your asp.net application process (As many of the attacks that are mitigated are designed to trick IIS into returning files outside your application folder). Thus any application defined error routines won't see it, however an IIS error page (which is what your configuring via webc.config) will be triggered.
I have a asp.net website which is supposed to upload files to a handler from a different application / domain. I'm using jQuery Form plugin. When trying to make an example on the same domain (uploading to the same domain) this setup works with success. When trying to upload file with from siteA to siteB I see in firebug that response from handler has been returned (in the Network tab) and is valid, however, the code never enters the 'success' handler, instead giving me such errors in the firebug console:
[jquery.form] Server abort: Error: Permission denied to access property 'document' (Error) log:
[jquery.form] cannot access response document: Error: Permission denied to access property 'document'
[jquery.form] aborting upload... aborted
In chrome it is:
Unsafe JavaScript attempt to access frame with URL http://domainB/handler.ashx from frame with URL domainA. Domains, protocols and ports must match.
Now, I am aware of the fact that there are some policies about ajax calls between domains, but it seems that jquery form plugin simply tries to access some url that is forbidden.
Does anyone have a workaround for it? Any solution please!:)
UPDATE:
I ended up hacking jquery.form so it doesn't throw cross-site exception and since I don't need actual result of upload - it works for me!
Check this and yes, this is a same-origin policy. There are ways to work this around using flash, iframes, jsonp etc but this will require editing a plugin.
I'm in the process of migrating a series of classic ASP web pages from a Windows 2000 server to a Windows 2008 R2 server. One of the pages uses CPSHOST.DLL (in the Scripts folder) to upload a file to the server.
The page in question uses a POST method on the form, but consistently returns a "Method Not Allowed" response when the page runs. I have changed the method from lowercase to uppercase, and I have configured the ISAPI and CGI Restrictions to allow the cpshost.dll to run.
The page in question prompts the userid for a file format type (3 possible options are available), and a file name. The form header is as follows:
<form enctype="multipart/form-data" method="POST" action="http://dcnb/scripts/cpshost.dll?PUBLISH?http://dcnb/scripts/dcn_cnam_repost.asp?user_id=jsommer&telco_code=GRGS" id=image_upload name=image_upload >
I tried changing the follwup .asp routine, in case it was throwing the error, but it made no difference (i.e., I changed the code to call a different web page than the repost.asp page, but to no avail.
The detailed error informaiton tells me the following:
Module: StaticFileModule, Notification: ExecuteRequestHandler, Handler: StaticFile, and Errorcode: 0x800700001.
The Requested URL is:
http://dcnb/scripts/cpshost.dll?PUBLISH?http://dcnb/scripts/dcn_cnam_repost.asp?user_id=jsommer&telco_code=GRGS
The physical path is listed as c:\inetpub\wwwroot\dcn\scripts\cpshost.dll, which is correct. The Logon Method and Logon User are both Anonymous.
Any help with this would be greatly appreciated. I have looked around for pure ASP solutions for uploading files (to eliminate the use of cpshost.dll), but have yet to find one that works in the IIS 7 environment. If anyone has any suggestions there, I'm all ears.
Thanks in advance for any help that you can provide. I appreciate it!
Can you try running Process Monitor when you request the page. Please confirm if the process is able access to cpshost.dll. If everything looks good, you can try running Failed Request Tracing to get some good information on what stage the request fails.
I have a situation where we're aggregating what amounts to marketing data from N number of clients, where a client can host a HTML form using any backend of their choice, each with the action of the form pointing to a path that we're hosting. Each client has a different URL, there's no auth (but there is some simple validation of the data) and it's all generally working just fine.
However, there's one small wrinkle that I can't seem to get my head around.
The aspx that is processing the submitted data resides at a path, let's call it ~/submit/default.aspx. The idea is that we should be able to hand to our partner a URL along the lines of "http://sample.com/submit/?foo=bar" as the action of their form. Doing this however results in a HTTP 405 error, "Resource not allowed".
Having the action of the form set as "http://sample.com/submit/default.aspx" works just fine and dandy however.
Default.aspx is set as one of the default document names in IIS 6.
The .aspx file extension is properly mapped to the correct .Net dll and has the verbs GET, HEAd, POST, and DEBUG activated for the mapping.
Those were the only two things I could think of to double check first--anyone else have any ideas? I'd have preferred to use URL rewriting / routing with IIS7, but that's unfortunately not an option--and I have a number of additional requirements where "clean" URLs will highly be preferable, so solving this problem is going to be a pretty core problem to get through.
IIRC, IIS will only use the default docs if the requested resource is a directory. Since the requested resource in the first case is not, it'll never make it through the default doc handlers - instead failing on a POST to an unregistered script extension (405).
it may depend on the document type of "http://sample.com/submit/?foo=bar"... if you IIS doesn't know how to handle the document type being returned to it (which then returns it to you, the client), then you may get an http 405 error - which means that it doesn't know how to handle that document type, server-wise. Maybe try putting something like
in your web.config file that drives the app. HTTP Handlers are modular pieces of code, written and compiled in a .net language, and act as kind of a 'servlet' if you're familiar with Java terms. It's a piece of code that writes out something to the client -- in your case maybe a rendering of a .doc file, found programmatically in your handler class.
for some reason, it didn't render my code sample!! you guys need to decode and encode less than and greater than signs for your "Your Answer" text box.... anyways,
<httpHandlers>
<add verb="your.class.to.handle.doc.files"/>
</httpHandlers>
is what should be in your web.config file.