(me): > > This means that at a properly designed site, GET is safe, > > but POST might order thousands of dollars worth of junk. > > You don't want that happening by accident.
David A. Desrosiers: > GET is most-decidedly UN-safe, but not for the > same reasons. [GET exposing data in plaintext] There is a reason that I specified "at a properly designed site". The standards state that GET should not be used for any action which requires confirmation - including any action for which the user may be held accountable. It specifies that GETs may be performed automatically, without a user's knowledge. Plenty of sites ignore this piece of the standard, but it is there. It is also true (as you point out) that the URL itself (=everything for a GET) is plaintext and likely to be cached, while the post-data *may* be encrypted, and *should* not be cached. > > I agree, but can't offer much help just yet. I have heard > > that IE can use the same XSLT, which might speed your testing. > Since when can IE do XSLT? That must be a new IE7 coming out.. In the Opera (another web browser) forums, we were discussing how to get a useful default stylesheet for XML. The standards state -- and Opera implements -- that content will be rendered, but tags and content will be effectively stripped out. It would often be more useful to see the tag names and attributes, but view source often leaves one huge line, instead of a properly indented document. CSS wouldn't work, because there was no way to refer to tagnames or arbitrary attributes. Someone posted a very good solution, but it involved pre-processing the text. He said it has been done with XSLT in MSIE. Perhaps he meant another IE related tool; I didn't test myself. (thus "heard" instead of just stating.) > > Is there anything that Plucker *should* handle? > Sure, lots of things. Text, graphics, HTML, maybe image maps? > Javascript? No. > Flash? No. Why are these different from image maps? If they require a live connection, that is a problem. A lot of JavaScript (including the stuff that started this discussion) could be pre-processed by the parser. Other javascript would require viewer changes, but could still be done offline. I agree that Plucker doesn't support it yet, and it will be enough work that it might take a while - but is there any reason to rule it out? > > There may not be one, if the post data is essential. (And > > if it weren't, GET would probably have worked.) > GET is not a replacement for POST, as you know. In practice, it sometimes can be. _______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
