I read something about this on PHP docs, but it's not clear to me:
Do the most widely used browsers (IE, FF, Chrome, Safari, Opera, ...) support this PUT method to upload files?
What HTML should I write to make the browser call the server via a PUT request? I mean do I need to write a FORM with an INPUT file field and just replace the attribute method="POST"with method="PUT"?
On the PHP docs (link above) they say a PUT request is much simpler than a POST request when uploading file, along with this advantage, what other advantages/disadvanatges do the PUT has got compared to the POST?
The PUT method cannot be used from a <form>. MSIE does not support it through the user GUI at all.
You can however use XMLHttpRequest. It seems to be defined in the standard and WHATWG / HTML5. My browser (Opera) obviously likes it.
http://old.mnot.net/javascript/xmlhttprequest/
IE might work too, as a short Google search suggests. And Firefox looks fine. Not checked Chrome or Webkit.
Server-site you need a specially designated script to handle an incoming PUT request. Look into the Apache docs. A mod_rewrite rule might usually do.
The genral adavantage of PUT is that there is no file encoding / marshalling into a multipart/* mime type required. In theory this allows uploading larger files more reliably. Allthough if you use PHP, it won't help you much. It's meant for Webservers with WebDAV support and/or direct filesystem write access. (Apache can save uploaded files itself, if you use that.)
I think the method is supported by most major browsers, but you can't account for every browser and other client that is out there. From a cursory look at the user contributed notes, this sometimes even needs server-side configuration to work.
Also, handling any additional form values you may want to send along with your file becomes more difficult.
I wouldn't use it. Way too much possible hassle for little actual gain.
The fact that PUT is rarely used for the purpose and only supported by major browsers excludes it from the any possible use here.
PUT is not very widely supported by browsers, and isn't generally used for interactive HTML forms.
Related
I know JavaScript or CSS for expample can be "compressed", "simplified" in order to be loaded faster. After simplifying they are difficult to be read by humans... and this is exactly what I need.
Is there anyway to make it automatically? Rename all variables to short random strings and make it all hypercompressed. I don't think it is a fool thing because I have seen this lot of times in javascript. The idea is to conserve the original source and upload the minified one.
There is no need for doing this. The Server reads the file, and the file never gets transferred to the user.
Therefore, compression is useless because there is no bandwidth saved.
CSS & JavaScript does however get transfered to the user, and therefore they can see it. A user can never see PHP unless you've done something wrong on your server. But then you need to worry about totally different things than compression.
If you want to compress it, this is basically useless, since you have it on the server and only the output gets transferred to the client.
If you want to make the code more difficult to read for other human beings, you're looking for something which is called an obfuscator.
There are a few php obfuscator engines out there, p.e.
http://www.codeeclipse.com/
http://www.truebug.com/
http://www.raizlabs.com/softwarephpobfuscator/
hello i was wondering what is the best way to upload a video to a website? should I do it through a page with GET and if so how is the file uploaded through http? i am a little confused as to how this would work? I am trying to upload files from iphone and android devices so i cannot use a form to do this, at least i don't think so is there a way to upload my file through http? or what is the most convenient way? thank you
The most pressing issue here is that the HTTP specification requires that GET requests be both safe and idempotent. Uploading video will likely be neither of these.
Section 9.1.1 Safe Methods in RFC 2616:
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
So no, bandwidth has nothing to do with it. HTTP itself says you shouldn't be uploading any sort of file by way of the GET method.
GET does not allow for enough bandwidth for a video. Use POST or PUT instead.
The official standard (RFC 2616) states
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
So, uploading a video would not come under 'retrieving information'.
POST should be used, like this:
<form action="process.php" method="post">
I have never understood why some people say making custom css for each browser is a bad thing. To keep my page size down and download times fast it makes perfect sense to me to make a custom css for the major browsers (especially IE in its many different forms), and a general catch all css for everything else.
If you want to send out a bloated, huge, Swiss army knife of the css world, for all situations then go right ahead I'm not going to stop you.
Fast detection of the browser is important when doing this. Loading a JavaScript file to detect the browser seems slow. So I would prefer to use php to detect the browser, and send out the specified css. Or at least a general browser specific css then use the JavaScript to load a more detailed version of the css.
But I've read article after article about why this is a bad thing. The main reason behind each of these articles is because the user agent can be faked. Or there using Firefox but the server thinks they're using IE7 so it sends out the wrong css file.
As a developer/designer of web apps why is this my problem? If you want to use Firefox, but tell my server your using safari or IE*, and get a crappy looking page, why is it my problem?
And don't throw that whole if the user can't see your site right they'll never come back, or some kind of similar argument at me. a normal user isn't going to be doing this. its only going to be the people who know how to do this, and will know whats wrong when my site looks crappy.
This is similar to looking at my site on a old Apple II (I have no clue how), and yelling at me because everything looks green.
So is there a good reason, not a personal preference, why I shouldn't use php to detect the browser and send out customized css files?
I do this mostly for the different versions of IE. It just seems like for some sites, adding the if IE6 and if IE7 parts just double or triple the size of the css file.
Typically when a user intentionally fakes the user agent string, it is because something is not viewable in the user's browser that should be. For example, some sites may restrict users to IE or Firefox, but the user is using Iceweasel on Debian. Iceweasel is just a Firefox renamed for trademarked reasons (there are a few other changes also), so there is no reason that the site should not work.
Realize that this happens because of (bad) browser detection, not despite it. I would say you don't need to be terribly concerned about this issue. Further, if you can just make your site reasonably cross-browser compatible, it won't matter at all. If you really want to use browser-specific CSS, and you don't want to do so all in one CSS file, don't let a fake user agent stop you.
As long as the only thing you're doing is changing style sheets, there is no valid reason as far as I can tell. If you're attempting to deliver custom security measures by browser, then you'll have issues.
Not sure about php but in Rails it is normal and dead simple practice to provide css files and different layouts based on the user agent particularly when considering that your site is just as likely to be accessed by any of the myriad of available mobile devices, never mind writing for the most popular (Currently Firefox) browsers and even writing custom MIME types if need be is also dead simple.
IMO not doing so is pure laziness on the coders part but then not all sites are developed by professional teams of developers with styling gurus at hand. Also in languages other than Rails it might not be so simple. Sorry, I haven't a clue about PHP so this may not be an appropriate reply
In my opinion, starting with normalize.css, and having a base style sheet to start, overriding the base styles as needed usually works along with making sure you set appropriate fallbacks. If you really need it a few media queries, and feature detection can go a long way.
One reason you shouldn't base things off of the browser is because major search engines like Google and Yahoo prohibit displaying different content for different browsers. GoogleBot can detect different CSS and HTML and you may get bad search positioning. Additionally, if you use any advertising services you may be in breach of their contract by displaying varying content.
I'm writing a very simple file sharing site in JS and PHP. I've got a drag/drop working, so the browser gets a file object upon drop, and from there I tried to send in a xhr request to an upload page. However, I can't seem to just drop a binary file object in a request header, and so was wondering how I'd go about base64 encoding it.
In PHP I'd use base64_encode, but I'm not even at the PHP page yet. Maybe you could suggest an alternative method to my current one?
Oh, and in the PHP that receives it, it writes to a semi-random file after base64_decodeing the file.
EDIT: I worked around it, but there isn't really a good answer. Thanks for helping!
Here's my demo: http://bernsteinbear.com/up
There is a function in the works that is currently only supported in Firefox, xhr.sendAsBinary, but for now you can do the Base64 encoding in Javascript with this custom function:
http://www.webtoolkit.info/javascript-base64.html
Alternatively, you can implement sendAsBinary yourself, as seen here:
http://hublog.hubmed.org/archives/001941.html
Just be aware that the Base64 method is currently the most compatible method.
Is there any reason you aren't using something like the Valumns File Uploder? I don't know why you're wanting to add a binary file "as a request header" (that makes little sense to me), but having to base64 encode it before sending seems a bit silly when HTTP can handle sending binary data in both directions quite easily (example with forms). Then again, I'm unfamiliar with the File API, so I'm not sure what special things you might be doing with it (are you transforming the file at all before sending?). Maybe I'm missing the point of this exercise.
While cross-site scripting is generally regarded as negative, I've run into several situations where it's necessary.
I was recently working within the confines of a very limiting content management system. I needed to include database code within the page, but the hosting server didn't have anything usable available. I set up a couple bare-bones scripts on my own server, originally thinking that I could use AJAX to import the contents of my scripts directly into the template of the CMS (thus retaining dynamic images, menu items, CSS, etc.). I was wrong.
Due to the limitations of XMLHttpRequest objects, it's not possible to grab content from a different domain. So I thought iFrame - even though I'm not a fan of frames, I thought that I could create a frame that matched the width and height of the content so that it would appear native. Again, I was blocked by cross-site scripting "protections." While I could indeed load a remote file into the iFrame, I couldn't execute JavaScript to modify its size on either the host page or inside the loaded page.
In this particular scenario, I wasn't able to point a subdomain to my server. I also couldn't create a script on the CMS server that could proxy content from my server, so my last thought was to use a remote JavaScript.
A remote JavaScript works. It breaks when the user has JavaScript disabled, which is a downside; but it works. The "problem" I was having with using a remote JavaScript was that I had to use the JS function document.write() to output any content. Any output that isn't JS causes script errors. In addition to using document.write() for every line, you also have to ensure that the content is escaped - or else you end up with more script errors.
My solution was as follows:
My script received a GET parameter ("page") and then looked for the file ({$page}.php), and read the contents into a variable. However, I had to use awkward buffering techniques in order to actually execute the included scripts (for things like database interaction) then strip the final content of all line break characters (\n) followed by escaping all required characters. The end result is that my original script (which outputs JavaScript) accesses seemingly "standard" scripts on my server and converts their standard output to JavaScript for displaying within the CMS template.
While this solution works, it seems like there may be a better way to accomplish the same thing. What is the best way to make cross-site scripting work specifically for the purpose of including content from a completely different domain?
You've got three choices:
Create a server side proxy script.
Create a remote script to read in remote dynamic HTML. Use a library like jQuery to make this easier. You can use the load function to inject HTML where needed. EDIT What I originally meant for example # 2 was utilizing JSONP, which requires the server side script to recognize the "callback=?" param.
Use a client side Flash proxy and setup a crossdomain.xml file on your server's web root.
Personally, I would call to that other domain on the server and get and parse the data there for use in your page. That way you avoid any problems and you get the power of a server-side language/platform for getting and parsing the data.
Not sure if that would work for your specific scenario...hard to know even with your verbose description...
You could try easyXDM, by including very little code, you can pass data or method calls between documents of different domains.
I've come across that YDN server side proxy script before. It says it's built to work with Yahoo's Search APIs.
Will it work with any domain, if you simply trim the Yahoo API code out? Or do you need to replace it with the domain you want it to work with?
iframe remote content can be accessed by local javascript.
The remote server just have to set the document.domain of the page.
Eg:
Site A contain an iframe with src='Site B/home.php'
home.php looks like this :
[php stuff]...[/php]
[script type='text/javascript']document.domain='Site A'[/script]