Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #14527 > unrolled thread

GET vs POST in AJAX

Back to article view | Back to comp.lang.javascript

Contents

  GET vs POST in AJAX CODEY <ed.pataky@gmail.com> - 2012-06-15 18:16 -0700
    Re: GET vs POST in AJAX Andrew Poulos <ap_prog@hotmail.com> - 2012-06-16 13:31 +1000
      Re: GET vs POST in AJAX CODEY <ed.pataky@gmail.com> - 2012-06-21 15:43 -0700
    Re: GET vs POST in AJAX Jason C <jwcarlton@gmail.com> - 2012-06-15 21:14 -0700
    Re: GET vs POST in AJAX Stefan Weiss <krewecherl@gmail.com> - 2012-06-16 13:13 +0200
      Re: GET vs POST in AJAX Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-16 12:22 -0700
        Re: GET vs POST in AJAX Stefan Weiss <krewecherl@gmail.com> - 2012-06-16 21:58 +0200
          Re: GET vs POST in AJAX Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-16 13:26 -0700
            Re: GET vs POST in AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-17 09:06 +0200
              Re: GET vs POST in AJAX Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-17 20:57 -0700
                Re: GET vs POST in AJAX Stefan Weiss <krewecherl@gmail.com> - 2012-06-18 15:23 +0200
                  Re: GET vs POST in AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-18 20:17 +0200
                    Re: GET vs POST in AJAX Stefan Weiss <krewecherl@gmail.com> - 2012-06-19 03:41 +0200
                      Re: GET vs POST in AJAX Andrew Poulos <ap_prog@hotmail.com> - 2012-06-19 12:25 +1000
                      Re: GET vs POST in AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-19 19:19 +0200
                    Re: GET vs POST in AJAX Dr J R Stockton <reply1225@merlyn.demon.co.uk.not.invalid> - 2012-06-19 20:44 +0100
                Re: GET vs POST in AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-18 20:14 +0200

#14527 — GET vs POST in AJAX

Hello, I have been using javascript for so many years, but I never really understood the difference between GET and POST ... obviously i understand the main idea, that GET is getting information and POST is sending, but since you can send and receive with POST, and because POST does not have the length/size restriction that GET does, I am not really sure why I would ever want to use GET instead of POST ... I am talking about ajax requests .... so the question is, is there a situation where you can use GET where you cannot use POST, or otherwise is there some benefit (speed, other) to using GET instead of POST? ... since there is a size restriction, and i have hit it multiple times in the past, I converted everything to POST, ... but i can do all the same things I did with GET, i just do them with POST, and I dont have to worry about the length of the data I am sending .. any comments here?

[toc] | [next] | [standalone]

#14529

On 16/06/2012 11:16 AM, CODEY wrote:
> Hello, I have been using javascript for so many years, but I never
> really understood the difference between GET and POST ... obviously i
> understand the main idea, that GET is getting information and POST is
> sending, but since you can send and receive with POST, and because
> POST does not have the length/size restriction that GET does, I am
> not really sure why I would ever want to use GET instead of POST ...
> I am talking about ajax requests .... so the question is, is there a
> situation where you can use GET where you cannot use POST, or
> otherwise is there some benefit (speed, other) to using GET instead
> of POST? ... since there is a size restriction, and i have hit it
> multiple times in the past, I converted everything to POST, ... but i
> can do all the same things I did with GET, i just do them with POST,
> and I dont have to worry about the length of the data I am sending ..
> any comments here?

Your question reads like a homework assignment. Anyhow here you go
<http://en.wikipedia.org/wiki/POST_%28HTTP%29#Use_for_submitting_web_forms>
and
<http://www.w3.org/2001/tag/doc/whenToUseGet.html>

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#14605

Andrew, ... haha no, i am a PHD student in electrical engineering, I only wish my homework was on javascript!

interesting stuff posted here, thank you all

On Friday, June 15, 2012 10:31:44 PM UTC-5, Andrew Poulos wrote:
> On 16/06/2012 11:16 AM, CODEY wrote:
> > Hello, I have been using javascript for so many years, but I never
> > really understood the difference between GET and POST ... obviously i
> > understand the main idea, that GET is getting information and POST is
> > sending, but since you can send and receive with POST, and because
> > POST does not have the length/size restriction that GET does, I am
> > not really sure why I would ever want to use GET instead of POST ...
> > I am talking about ajax requests .... so the question is, is there a
> > situation where you can use GET where you cannot use POST, or
> > otherwise is there some benefit (speed, other) to using GET instead
> > of POST? ... since there is a size restriction, and i have hit it
> > multiple times in the past, I converted everything to POST, ... but i
> > can do all the same things I did with GET, i just do them with POST,
> > and I dont have to worry about the length of the data I am sending ..
> > any comments here?
> 
> Your question reads like a homework assignment. Anyhow here you go
> <http://en.wikipedia.org/wiki/POST_%28HTTP%29#Use_for_submitting_web_forms>
> and
> <http://www.w3.org/2001/tag/doc/whenToUseGet.html>
> 
> Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#14530

On Friday, June 15, 2012 9:16:14 PM UTC-4, CODEY wrote:
> Hello, I have been using javascript for so many years, but I never really 
> understood the difference between GET and POST ... obviously i understand the 
> main idea, that GET is getting information and POST is sending, but since you 
> can send and receive with POST, and because POST does not have the 
> length/size restriction that GET does, I am not really sure why I would ever 
> want to use GET instead of POST ...

I tend to use GET more often than POST so that I can modify variables through the URL. If you're writing scripts for command line, then that's probably irrelevant, but for website purposes, I do it a lot.

The only time I really use POST is if:

1. I want to prevent the end user from accessing the same results without resubmitting;

2. I'm submitting a password or other sensitive data;

3. The length of what's being submitted is an issue.


> I am talking about ajax requests .... so the question is, is there a 
> situation where you can use GET where you cannot use POST, or otherwise is 
> there some benefit (speed, other) to using GET instead of POST? ... since 
> there is a size restriction, and i have hit it multiple times in the past, I 
> converted everything to POST, ... but i can do all the same things I did with 
> GET, i just do them with POST, and I dont have to worry about the length of 
> the data I am sending .. any comments here?

I'm going through a similar debate for my own programming. On my end, I'm calling a script via Ajax, and then submitting a form within that Ajax. After submitting the form, I show a "success" page so that the form doesn't just disappear.

Since it's being initially loaded with a link (not a form submission), any variables are sent by GET. Like:

ajax('whatever.php?var1=something&var2=something_else');

After the form in the requested script is submitted, I need to retain those variables, so I have to submit the form via GET.

As an alternative, though, I could parse all GET and POST variables into string variables in the requested script, and then still use POST if I wanted. It's not important for my script, but still, it's an option.

[toc] | [prev] | [next] | [standalone]

#14532

On 2012-06-16 03:16, CODEY wrote:
> Hello, I have been using javascript for so many years, but I never
> really understood the difference between GET and POST ... obviously i
> understand the main idea, that GET is getting information and POST is
> sending, but since you can send and receive with POST, and because
> POST does not have the length/size restriction that GET does, I am
> not really sure why I would ever want to use GET instead of POST ...
> I am talking about ajax requests ....

As you say, the difference is mostly semantic. In a nutshell,

- GET retrieves information from the server. It should not have any
other side effects changing the state on the server, or at least the
client may assume that the request is "safe".

- POST sends data to the server. The client has to assumed that
successful sending can change the state of the server (by adding the
POSTed data to the server's data store, or causing other changes).

The W3 link Andrew Poulos posted explains the difference in detail. The
authoritative specifications are in RFC2616 for HTTP/1.1 and RFC1945 for
HTTP/1.0.

The short of it is, never use GET to add/change/delete information on
the server.

If the server provides a (partially) RESTful API, the distinction
between different request methods may be enforced by the server, and the
client may not have a choice which method to use.

In practice, with AJAX/XMLHttpRequest, another consideration is often
more important: POST responses cannot be cached on the client. This can
be (ab)used to prevent client side caching.

For example: Assuming that both server and client are configured to
allow caching, if the client sends a GET request via AJAX, it may
receive a response indicating that the content will not change for the
next 10 days. The next time the client uses GET for the same URI, the
request may not even be sent to the server, because the response is
already locally cached.

  Client: GET: show me the todo list for user X
  Server: ok, here's the todo list
  Client: POST: add entry to todo list for user X
  Server: ok, added
  Client: GET: show me the todo list for user X

If the results of the first GET were cached, this request may never be
sent at all. In a perfect world, the server will tell the client not to
cache the first response, and the client will respect that, but in
practice, all kinds of things can go wrong with caching. So people often
just use POST to prevent caching, even if it's semantically incorrect.

- stefan

[toc] | [prev] | [next] | [standalone]

#14537

On 6/16/12 4:13 AM, Stefan Weiss wrote:
> On 2012-06-16 03:16, CODEY wrote:
>> Hello, I have been using javascript for so many years, but I never
>> really understood the difference between GET and POST ... obviously i
>> understand the main idea, that GET is getting information and POST is
>> sending, but since you can send and receive with POST, and because
>> POST does not have the length/size restriction that GET does, I am
>> not really sure why I would ever want to use GET instead of POST ...
>> I am talking about ajax requests ....
>
> As you say, the difference is mostly semantic. In a nutshell,
>
> - GET retrieves information from the server. It should not have any
> other side effects changing the state on the server, or at least the
> client may assume that the request is "safe".
Actually, I recall reading somewhere that "GET" need only be idempotent. 
The first call is allowed to change server state, but calling it over 
and over again will have no further effect. This is sometimes difficult 
to implement. So if you have a request that can change state, and you 
don't have a way on the server side to prevent it changing the state 
multiple time, then you should use POST.
>
> - POST sends data to the server. The client has to assumed that
> successful sending can change the state of the server (by adding the
> POSTed data to the server's data store, or causing other changes).
Exactly. A POST isn't idempotent.
>
> The W3 link Andrew Poulos posted explains the difference in detail. The
> authoritative specifications are in RFC2616 for HTTP/1.1 and RFC1945 for
> HTTP/1.0.
>
> The short of it is, never use GET to add/change/delete information on
> the server.
>
> If the server provides a (partially) RESTful API, the distinction
> between different request methods may be enforced by the server, and the
> client may not have a choice which method to use.
>
> In practice, with AJAX/XMLHttpRequest, another consideration is often
> more important: POST responses cannot be cached on the client. This can
> be (ab)used to prevent client side caching.
>
> For example: Assuming that both server and client are configured to
> allow caching, if the client sends a GET request via AJAX, it may
> receive a response indicating that the content will not change for the
> next 10 days. The next time the client uses GET for the same URI, the
> request may not even be sent to the server, because the response is
> already locally cached.
>
>    Client: GET: show me the todo list for user X
>    Server: ok, here's the todo list
>    Client: POST: add entry to todo list for user X
>    Server: ok, added
>    Client: GET: show me the todo list for user X
>
> If the results of the first GET were cached, this request may never be
> sent at all. In a perfect world, the server will tell the client not to
> cache the first response, and the client will respect that, but in
> practice, all kinds of things can go wrong with caching. So people often
> just use POST to prevent caching, even if it's semantically incorrect.
>
> - stefan

[toc] | [prev] | [next] | [standalone]

#14538

On 2012-06-16 21:22, Daniel Pitts wrote:
> On 6/16/12 4:13 AM, Stefan Weiss wrote:
>> As you say, the difference is mostly semantic. In a nutshell,
>>
>> - GET retrieves information from the server. It should not have any
>> other side effects changing the state on the server, or at least the
>> client may assume that the request is "safe".

> Actually, I recall reading somewhere that "GET" need only be idempotent. 
> The first call is allowed to change server state, but calling it over 
> and over again will have no further effect.

I've never heard that before. It would be be interesting to know where
you read that. The RFC 2616 states that

| 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.

GET should be idempotent in addition to being safe.

There was a famous case of SNAFU involving a company's intranet web
application and manager who had installed the Alexa toolbar. Every time
the manager used the web app, data would mysteriously go missing. It
turned out that the reason for this was some kind of link pre-fetching
feature in the Alexa toolbar in combination with links like this in the
web app:

<a href="/foo/deleteItem?id=12345" onclick="return confirm(...)">...</a>

The prefetcher ignored the script and went on to call the "deleteItem"
action for all items in view.

This should serve as a lesson for never using GET when the resulting
action isn't safe.

- stefan

[toc] | [prev] | [next] | [standalone]

#14539

On 6/16/12 12:58 PM, Stefan Weiss wrote:
> On 2012-06-16 21:22, Daniel Pitts wrote:
>> On 6/16/12 4:13 AM, Stefan Weiss wrote:
>>> As you say, the difference is mostly semantic. In a nutshell,
>>>
>>> - GET retrieves information from the server. It should not have any
>>> other side effects changing the state on the server, or at least the
>>> client may assume that the request is "safe".
>
>> Actually, I recall reading somewhere that "GET" need only be idempotent.
>> The first call is allowed to change server state, but calling it over
>> and over again will have no further effect.
>
> I've never heard that before. It would be be interesting to know where
> you read that.
I don't remember where I first read that, but here is a top result for 
the Google search "get method idempotent"

<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>

> The RFC 2616 states that
> | 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.
>
> GET should be idempotent in addition to being safe.
Agreed.
>
> There was a famous case of SNAFU involving a company's intranet web
> application and manager who had installed the Alexa toolbar. Every time
> the manager used the web app, data would mysteriously go missing. It
> turned out that the reason for this was some kind of link pre-fetching
> feature in the Alexa toolbar in combination with links like this in the
> web app:
>
> <a href="/foo/deleteItem?id=12345" onclick="return confirm(...)">...</a>
>
> The prefetcher ignored the script and went on to call the "deleteItem"
> action for all items in view.
I've heard several incarnations of this story. Including a crawler 
gaining access to the site because it wasn't properly insulated by 
passwords and firewalls.
>
> This should serve as a lesson for never using GET when the resulting
> action isn't safe.
And never install toolbars ;-)

[toc] | [prev] | [next] | [standalone]

#14543

Daniel Pitts wrote:

> On 6/16/12 12:58 PM, Stefan Weiss wrote:
>> On 2012-06-16 21:22, Daniel Pitts wrote:
>>> On 6/16/12 4:13 AM, Stefan Weiss wrote:
>>>> As you say, the difference is mostly semantic. In a nutshell,
>>>> - GET retrieves information from the server. It should not have any
>>>> other side effects changing the state on the server, or at least the
>>>> client may assume that the request is "safe".
>>
>>> Actually, I recall reading somewhere that "GET" need only be idempotent.
>>> The first call is allowed to change server state, but calling it over
>>> and over again will have no further effect.
>>
>> I've never heard that before. It would be be interesting to know where
>> you read that.
> I don't remember where I first read that, but here is a top result for
> the Google search "get method idempotent"
> 
> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>

This is Usenet.  Please do not only post URLs of resources which you *think* 
support your position (for the dedicated reader to switch medium to find out 
whether it really does), but *make an argument* using the resource as 
reference (best by citing it *and* quoting the relevant parts).  Refer
to Stefan's posting for a good example how that can be done.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#14548

On 6/17/12 12:06 AM, Thomas 'PointedEars' Lahn wrote:
> Daniel Pitts wrote:
>
>> On 6/16/12 12:58 PM, Stefan Weiss wrote:
>>> On 2012-06-16 21:22, Daniel Pitts wrote:
>>>> On 6/16/12 4:13 AM, Stefan Weiss wrote:
>>>>> As you say, the difference is mostly semantic. In a nutshell,
>>>>> - GET retrieves information from the server. It should not have any
>>>>> other side effects changing the state on the server, or at least the
>>>>> client may assume that the request is "safe".
>>>
>>>> Actually, I recall reading somewhere that "GET" need only be idempotent.
>>>> The first call is allowed to change server state, but calling it over
>>>> and over again will have no further effect.
>>>
>>> I've never heard that before. It would be be interesting to know where
>>> you read that.
>> I don't remember where I first read that, but here is a top result for
>> the Google search "get method idempotent"
>>
>> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>
>
> This is Usenet.
I'm aware.
> Please do not only post URLs of resources which you *think*
> support your position
I've been on here for years in other newsgroups. Each of which has their 
own guides for such matters. Thanks for informing me. I only wish the 
voice was as kind as the act.
>(for the dedicated reader to switch medium to find out
> whether it really does), but *make an argument* using the resource as
> reference (best by citing it *and* quoting the relevant parts).   Refer
> to Stefan's posting for a good example how that can be done.

I was not and am not making an argument. My original post was "I recall 
reading x," Stefan's reply was "It would be be interesting to know where 
you read that," and my final response was, in fact, a URL where one 
could read that.

Also, I'd rather not worry about copyright infringement just so a less 
"dedicated" reader would be able to see my references.  This isn't the 
90's any more. It isn't even the 00's anymore.  Switching mediums should 
be easy, and provide more utility, than simply reading a "copy and 
pasted" potentially copyright material. As well as leaving it open to 
the possibility that I'm intentionally misquoting or eliding contrary 
information.

[toc] | [prev] | [next] | [standalone]

#14549

On 2012-06-18 05:57, Daniel Pitts wrote:
>>> I don't remember where I first read that, but here is a top result for
>>> the Google search "get method idempotent"
>>>
>>> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>
...
> My original post was "I recall reading x," Stefan's reply was "It
> would be be interesting to know where you read that," and my final
> response was, in fact, a URL where one could read that.

But that's the same document I was quoting from, and it says the
opposite of what you remember reading (that GET only needs to be
idempotent).

> Also, I'd rather not worry about copyright infringement.

Copyright violations on Usenet? Who would have thought...
I think it's safe to say that copyright holders are more concerned with
the alt.binaries hierarchies than comp.lang.

Quoting small excerpts from a technical document in a discussion is a
typical case of fair use.

- stefan

[toc] | [prev] | [next] | [standalone]

#14551

Stefan Weiss wrote:

> On 2012-06-18 05:57, Daniel Pitts wrote:
>> Also, I'd rather not worry about copyright infringement.
> 
> Copyright violations on Usenet? Who would have thought...
> I think it's safe to say that copyright holders are more concerned with
> the alt.binaries hierarchies than comp.lang.
> 
> Quoting small excerpts from a technical document in a discussion is a
> typical case of fair use.

AFAIK, "Fair use" is a concept of U.S. law only.  I do not think it even 
applies here.


PointedEars, IANAL
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#14553

On 2012-06-18 20:17, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> Quoting small excerpts from a technical document in a discussion is a
>> typical case of fair use.
> 
> AFAIK, "Fair use" is a concept of U.S. law only.

This is getting pretty far off-topic, and IANAL, but... The Internet
Society (who holds the copyright on that RFC), Daniel Pitts, and his
Usenet provider are all based in the US. Which law do you think would
apply in this case?

(This is assuming the purely hypothetical case of a complaint or suit by
an organization whose mission is "to assure the open development,
evolution and use of the Internet for the benefit of all people
throughout the world".)

> I do not think it even applies here.

Again, IANAL, but from everything I've read, I'm pretty certain that
Fair Use does apply to a short quotation from a freely available
standard in a discussion group:

| […] the fair use of a copyrighted work […] for purposes such as
| criticism, comment, news reporting, teaching (including multiple
| copies for classroom use), scholarship, or research, is not an
| infringement of copyright.

Or did "here" mean a different physical location, such as Germany or
Austria? That's a whole different ball of wax, because neither Copyright
nor Fair Use exist there. They have Urheberrecht, Zitatrecht and
Verwertungsrechte instead. Even so, short non-commercial quotations are
explicitly permitted in both countries.

- stefan

[toc] | [prev] | [next] | [standalone]

#14554

On 19/06/2012 11:41 AM, Stefan Weiss wrote:
> On 2012-06-18 20:17, Thomas 'PointedEars' Lahn wrote:
[...]
> | […] the fair use of a copyrighted work […] for purposes such as
> | criticism, comment, news reporting, teaching (including multiple
> | copies for classroom use), scholarship, or research, is not an
> | infringement of copyright.
>
> Or did "here" mean a different physical location, such as Germany or
> Austria? That's a whole different ball of wax, because neither Copyright
> nor Fair Use exist there. They have Urheberrecht, Zitatrecht and
> Verwertungsrechte instead. Even so, short non-commercial quotations are
> explicitly permitted in both countries.

Yep, in Australia there's "fair dealing" which is different from "fair use":
<http://en.wikipedia.org/wiki/Copyright_law_of_Australia#Fair_dealing_and_other_exceptions>

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#14568

Stefan Weiss wrote:

> On 2012-06-18 20:17, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> Quoting small excerpts from a technical document in a discussion is a
>>> typical case of fair use.
>> AFAIK, "Fair use" is a concept of U.S. law only.
> 
> This is getting pretty far off-topic, and IANAL, but... The Internet
> Society (who holds the copyright on that RFC), Daniel Pitts, and his
> Usenet provider are all based in the US. Which law do you think would
> apply in this case?

I do not know.  I think it is a legal grey area.

> (This is assuming the purely hypothetical case of a complaint or suit by
> an organization whose mission is "to assure the open development,
> evolution and use of the Internet for the benefit of all people
> throughout the world".)

My point exactly.
 
>> I do not think it even applies here.
> 
> […]
> Or did "here" mean a different physical location, such as Germany or
> Austria?

Of course not.

> That's a whole different ball of wax, because neither Copyright
> nor Fair Use exist there. They have Urheberrecht, Zitatrecht and
> Verwertungsrechte instead. Even so, short non-commercial quotations are
> explicitly permitted in both countries.

Please tell me something I do not know yet.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#14577

In comp.lang.javascript message <3559212.dG70XP5YAQ@PointedEars.de>,
Mon, 18 Jun 2012 20:17:47, Thomas 'PointedEars' Lahn
<PointedEars@web.de> posted:

>Stefan Weiss wrote:
>
>> On 2012-06-18 05:57, Daniel Pitts wrote:
>>> Also, I'd rather not worry about copyright infringement.
>>
>> Copyright violations on Usenet? Who would have thought...
>> I think it's safe to say that copyright holders are more concerned with
>> the alt.binaries hierarchies than comp.lang.
>>
>> Quoting small excerpts from a technical document in a discussion is a
>> typical case of fair use.
>
>AFAIK, "Fair use" is a concept of U.S. law only.  I do not think it even
>applies here.

Naive.  Consult the obvious references, including
<http://de.wikipedia.org/wiki/Urheberrecht#Art_und_Umfang_des_Urheberrec
hts>.

RBTD.

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[toc] | [prev] | [next] | [standalone]

#14550

Daniel Pitts wrote:

> On 6/17/12 12:06 AM, Thomas 'PointedEars' Lahn wrote:
>> Daniel Pitts wrote:
>>> On 6/16/12 12:58 PM, Stefan Weiss wrote:
>>>> On 2012-06-16 21:22, Daniel Pitts wrote:
>>>>> On 6/16/12 4:13 AM, Stefan Weiss wrote:
>>>>>> As you say, the difference is mostly semantic. In a nutshell,
>>>>>> - GET retrieves information from the server. It should not have any
>>>>>> other side effects changing the state on the server, or at least the
>>>>>> client may assume that the request is "safe".
>>>>
>>>>> Actually, I recall reading somewhere that "GET" need only be
>>>>> idempotent. The first call is allowed to change server state, but
>>>>> calling it over and over again will have no further effect.
>>>>
>>>> I've never heard that before. It would be be interesting to know where
>>>> you read that.
>>> I don't remember where I first read that, but here is a top result for
>>> the Google search "get method idempotent"
>>>
>>> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>
>>
>> This is Usenet.
> I'm aware.

No, you are not.  Usenet is _not_ a part of the Web or the Internet 
(although there are intersections).  However, the resource you are referring 
to, by URL, is.

>> Please do not only post URLs of resources which you *think*
>> support your position
> I've been on here for years in other newsgroups. Each of which has their
> own guides for such matters.

I am rather certain that this guideline applies to all *Usenet* newsgroups.

> Thanks for informing me. I only wish the voice was as kind as the act.

You do not know me and should be rather slow second-guessing my intentions.

>> (for the dedicated reader to switch medium to find out
>> whether it really does), but *make an argument* using the resource as
>> reference (best by citing it *and* quoting the relevant parts).   Refer
>> to Stefan's posting for a good example how that can be done.
> 
> I was not and am not making an argument.

And that is the problem.  This is a discussion.  If you want to make a point 
here, you are *required* to formulate a convincing argument.  There is 
enough unfounded babbling already.

> My original post was "I recall reading x," Stefan's reply was "It would be
> be interesting to know where you read that," and my final response was, in
> fact, a URL where one could read that.

Do you not see that this is insufficient because you may be wrong?

> Also, I'd rather not worry about copyright infringement

*Proper* quotation from *published* sources is *never* infringement of 
copyright.  (IANAL)  Science could hardly work without quotation now and 
then; neither could a newsgroup (which is why the default in NetNews clients 
is to quote the precursor; users are expected to trim it to the parts they 
are referring to in their followup).

In any case, with regard to violations of rights, you should be more 
concerned about not violating the rules of conduct set forth by your service 
provider, which you might be doing by forging message headers.  It would be 
impolite at least.

> just so a less "dedicated" reader would be able to see my references. 

Science teaches us that references without argument are worthless, as are 
arguments without references to support them.

> This isn't the 90's any more.

True.

> It isn't even the 00's anymore. 

Also true.  (However, "00's" is a bit awkward a term.  I think you were 
looking for "'90s" and "2000s" instead.)

> Switching mediums should be easy,

That is an obvious fallacy.

> and provide more utility, than simply reading a "copy and
> pasted" potentially copyright material. As well as leaving it open to
> the possibility that I'm intentionally misquoting or eliding contrary
> information.

You are missing the point, and your logic is flawed.  *Omitting* the context 
in which you think the reference applies was/is the mistake; not to provide 
it.


HTH

PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web