Is there any data regarding how browsers actually support rest http verbs (especially PUT, DELETE). This question is mostly motivated by the fact that many sources (such as this stackoverflow answer) inform that most browsers don't suport PUT and DELETE but don't say which.
Rails solves this using a patch on the client, and reversing the patch on the server, but I wonder, for instance, which browsers wouldn't need such hack.
When in doubt, ask Anne:
http://annevankesteren.nl/2007/10/http-method-support
It's a couple of years old, but it gives a clean bill of health to PUT and DELETE, but it also tries different cases of more obscure verbs like TRACE and PROPFIND:
Van Kesteren tested Firefox 3, Opera 9.5 and Internet Explorer 7, a mix of pre-release and releases. GET and POST worked as expected, and all supported the standard set of http methods from RFC 2616. There are some casing issues, so you should try to stick with uppercase always; TRACE and OPTIONS are edge cases with problems found in Firefox and Opera, respectively. CONNECT and TRACE and SEARCH are problematic for IE. Bear in mind that this was written in 2007 so YMMV.
I think the whole confusion over browsers not supporting other than GET and POST stems from the fact that the HTML specification lists only these two in the HTML <form> element:
The method attribute of the FORM element specifies the HTTP method used to send the form to the processing agent. This attribute may take two values:
get: With the HTTP "get" method, the form data set is appended to the URI specified by the action attribute (with a question-mark ("?") as separator) and this new URI is sent to the processing agent.
post: With the HTTP "post" method, the form data set is included in the body of the form and sent to the processing agent.
This is the reason why browsers only support GET and POST natively in HTML; since the standard says so.
The current (January 2014) XMLHttpRequest specification on the other hand states explicitly that request methods should be allowed through with some exceptions (CONNECT, TRACE or TRACK), and that RFC2616 methods should be uppercased:
\6. If method is a case-insensitive match for CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE, or TRACK, subtract 0x20 from each byte in the range 0x61 (ASCII a) to 0x7A (ASCII z).
If it does not match any of the above, it is passed through literally, including in the final request.
EDIT Another source that has come to more or less the same conclusion: That XMLHttpRequest supports PUT and DELETE: http://jshirley.vox.com/library/post/xmlhttprequest-and-rest.html (warning, broken link as of May 2014).
EDIT The question has been asked before of course, but the two year old answers are still valid.
EDIT Short resume of Anne van Kesteren's page from 2007, and added section on HTML vs XMLHttpRequest
See the PutDeleteSupport page of the Atom Wiki. You might be interested in browsing other Atom Wiki pages related to HTTP.
Related
I'm trying to lock down my pages with a content security policy (CSP). The default CSP is too restrictive (and I cannot change the code to make it compliant, as it comes from a 3rd party), so I'm trying to define the minimal set of permissions in the CSP. To that end, I'd like to use style-src-attr and script-src-attr. And I'd like to use these with a nonce. I can see how to specify the nonce for both of these in the CSP. What I'm not sure about is how to specify the nonce for the html element (in the case of style-src-attr) and the javascript object (in the case of script-src-attr). I looked for an example, but couldn't find anything. Please give an example of how this could be done.
I stumbled over this question in actually preparing a lecture on the topic. The answer to the question is: you cannot.
Looking at the CSP Spec (https://www.w3.org/TR/CSP3/#match-element-to-source-list), only script or style tags can be nonced. The -attr variants do not apply to stand-alone elements (script tags, style tags, or links to CSS files), as per the spec (https://w3c.github.io/webappsec-csp/#directive-script-src-attr)
The script-src-attr directive applies to event handlers and, if present, it will override the script-src directive for relevant checks.
Bottom line, in the current specificiation, it should not be possible to allow event handlers through nonces. It is possible to rely on unsafe-hashes and put the hashes of known event handlers in there, but even that is not fully supported in browser (FF and Safari lack support, see https://caniuse.com/mdn-http_headers_csp_content-security-policy_unsafe-hashes)
Whenever I save or create a node of a certain user-defined type, I am back in the edit window instead of switching to the first tab labeled view. All my fields (body, title etc. are as they were and no message appears, neither directly on the page nor in the watchdog database log. The validation is working, though, because I see those 'required' messages as soon as I try to save without Title for example.
The strange thing is that when I create a new content type, or use the predefined story and page types, I can edit and create nodes. In the latter case, Drupal answers with an 302 redirect, whereas with the proplematic content types, only a 200 HTTP status is returned.
The issue doesn't seem to be related to either JavaScript (on or off, no difference), Browser (tried Chrome and Firefox) or WYSIWYG (used input formats with and without).
I'm using Drupal 6.22 and the CCK. I have about 7 content types, some of them with fields. I am not using Rules, but a multitude of modules, all of which are up-to-date. I will post a list if this issue can't be solved otherwise.
I have spend the last hours trying to figure this out, both by looking at my installation (settings, database) and by searching Google & Co.
Any ideas?
The situation appeared because Drupal translated both the Upload and the Save button to one word, Speichern. The FileField issue tracker contains the corresponding thread: http://drupal.org/node/684426
The ImageField and Locale modules, along with a language such as German or Finnish were partly responsible for the trouble.
I once read a page a few years ago about the various browsers' differing implementations of behaviour when a link with an empty href is clicked.
some of them linked to the directory (/path/to/file?query → /path/to/)
some of them linked to the exact same URI (/path/to/file?query → /path/to/file?query)
some of them linked to the same page (/path/to/file?query → /path/to/file)
...and various other behaviours.
Is the behaviour defined in a specification?
If so, what is the correct behaviour?
If so, have the latest versions of the big five browsers today fixed their implementations?
Since there's no "specification" for contents of HREF (at least in HTML 4), the browsers can do whatever they damn well please.
UPDATE However, aside from HTML, there's an RFC3986: Uniform Resource Identifier (URI): Generic Syntax. It has section 4.4. Same-Document Reference which says:
When a URI reference refers to a URI that is, aside from its fragment
component (if any), identical to the base URI (Section 5.1), that
reference is called a "same-document" reference. The most frequent
examples of same-document references are relative references that are empty ...
I do not necessarily read the above as "an empty URI MUST cause the client to reload the same socument's URI", but it does sound like a "best practice" type of wording; so if I was implementing my own browser I'd almost certainly follow such a behavior.
On a related note, here's a good recent 3/2010) roundup of how browsers treat empty src attribute of <img> tag: http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/ and http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/ . Please note that it is a big deal, since having and empty img src would cause the page to endlessly re-load itself in the worst case scenario.
I am working on a site that have an international aim; I.o.w., logged in users can add text in their own language. I am hoping for international page names and content.
An URL example, like the Japanese Wikipedia: http://ja.wikipedia.org/wiki/メインページ (Both pagename and content text).
I know by using UTF-8, I can do this, but how should I control it?
UTF-8 contains way to many languages/letters to control in a script, I guess, so how safe/unsafe is it to allow people to add UTF-8 text?
I can see that someone could add harmful code this way, but how to prevent it?
All information regarding safety/control when using UTF-8 is appreciated!
EDIT: PS! I use PHP and MySQL.
Warning: perhaps a slightly rusty response:
Note: not discussing host name (IDNS) issues.
The only completely safe thing here is to use %-escaped UTF-8. Some browsers will display this as what you want, and some will display the %-escapes. (e.g. http://foo.bar/%ee%cc%cf.html)
If you put 'real UTF-8' in the URLs, many things will work, but there may be unpleasant surprises lurking for some people in some browsers. I'm reading your question as dealing with 100% static content. If you are trying to do this with code behind the site, you have additional issues to work on.
The 'unpleasant surprises' would be (a) people finding the %xx's in the URL unreadable, (b) a browser that melts, (c) some data scraping or aggregating application that melts.
I wish I were more up to date on this, but I'm not, so my recommendation is to deploy a test site and then try to access it with everything you can put your hands on, including mobile phones. Persuade Google to index it, and see what happens there.
For domain names, this is called IDN. For page names, you may want to think of the possibility of IDN spoofs.
It's safe as long as you don't interpret it literally as SQL (SQL injection) or HTML (XSS) or any other language. Just escape any user-controlled input (request URL, request headers, request parameters, request body, etc..etc..) at the point it's going to be used in SQL or HTML.
It's unclear what server side programming language you're using, so I can't go further in detail.
I'm looking into ways to develop an extension for IE6+ that will allow handling of custom MIME types.
As an example, I need to be able to take a document with a custom MIME type that is returned by the server, perform some processing on it, and then change the MIME type back to something that IE can natively handle, such as text/html or image/jpeg.
I am familiar with the urlmon MIME filters, but they have a huge weakness; they are only invoked for the top level document, and not for any of the additional page content such as images and the like.
The one way that I can think of that will work is to hook the HTTP/S protocol handlers using vtable/iat patches, similar to the way Google Gears works, to be able to intercept the response headers, and modify the headers and response body when a document with the specified MIME type is received.
I'm wondering if anybody else has any good ideas on how this could be accomplished in a less hacky/intrusive way.
Edit:
Just thought I'd follow up on this and mention that I went with the vtable patch into the HTTP/S protocol handlers, and it worked much better than I expected. If anybody else is looking to do something like this, I highly recommend taking a look at the HttpHandlerPatch class in Google Gears for some inspiration.
Several years ago, I wrote such extensions, BHO, IE toolbars, etc., based on a book called Shell Programming in VB6. The book I used is this one: http://oreilly.com/catalog/9781565926707/ This book tells you how to hook and trap messages coming into IE. I wrote a kind of screen scraper (post-render style not like a spider that doesn't execute the javascript first). It was based on IE5 but the extensions still work with IE6. I probably still have the VB6 source somewhere. I am not offering to upgrade it to .Net for you though.
PS. The review on that page by Haroeris Astrum is by me :)