<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: GET vs POST and URL security	</title>
	<atom:link href="https://www.selikoff.net/2010/05/02/get-vs-post-and-url-security/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.selikoff.net/2010/05/02/get-vs-post-and-url-security/</link>
	<description>Java/J2EE Software Development and Technology Discussion Blog</description>
	<lastBuildDate>Sat, 08 May 2010 08:00:13 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		By: Ulf		</title>
		<link>https://www.selikoff.net/2010/05/02/get-vs-post-and-url-security/comment-page-1/#comment-2446</link>

		<dc:creator><![CDATA[Ulf]]></dc:creator>
		<pubDate>Sat, 08 May 2010 08:00:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.selikoff.net/?p=1952#comment-2446</guid>

					<description><![CDATA[@psi: No, GET and POST should not be used interchangeably; in fact, the HTTP spec is quite clear on the fact that web apps that do so are semantically broken. But POST can be used for purposes for which GET would be sufficient -idempotent operations- if POST&#039;s characteristics are better suited for it - like hiding parameters. You&#039;re right that GET should not be used for operations that change state.]]></description>
			<content:encoded><![CDATA[<p>@psi: No, GET and POST should not be used interchangeably; in fact, the HTTP spec is quite clear on the fact that web apps that do so are semantically broken. But POST can be used for purposes for which GET would be sufficient -idempotent operations- if POST&#8217;s characteristics are better suited for it &#8211; like hiding parameters. You&#8217;re right that GET should not be used for operations that change state.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: psi		</title>
		<link>https://www.selikoff.net/2010/05/02/get-vs-post-and-url-security/comment-page-1/#comment-2435</link>

		<dc:creator><![CDATA[psi]]></dc:creator>
		<pubDate>Mon, 03 May 2010 11:58:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.selikoff.net/?p=1952#comment-2435</guid>

					<description><![CDATA[This is very interesting.  The strange think that I see here, though, is the implication that GET and POST could/should/might be used interchangeably to accomplish the same operation.  I was under the impression that they had very discreet roles: GET is an idempotent operation used to retrieve a resource from the server, POST is an operation used to create it, and PUT is an operation used to update it.  Could/should/might GET, POST and PUT both be correctly used for the same form submission, then?  POST and PUT seem the right verbs for a form submission that changes state on the server (Add a comment to a blog), and GET seems the right verb for a form submission that is requesting specific information from the server (like using a search engine to find pages that match a set of keywords).  

This would have the side-effect of causing updates of bank account or social security information to be POSTs or PUTs (which don&#039;t use the query-string).  The only issues we would ever have would be:

-The user is trying to GET a resource from the server using some secure field (like a social security number)
-The developer has used GET to do form submissions involving creates or updates

Are there actually valid use-cases for either?]]></description>
			<content:encoded><![CDATA[<p>This is very interesting.  The strange think that I see here, though, is the implication that GET and POST could/should/might be used interchangeably to accomplish the same operation.  I was under the impression that they had very discreet roles: GET is an idempotent operation used to retrieve a resource from the server, POST is an operation used to create it, and PUT is an operation used to update it.  Could/should/might GET, POST and PUT both be correctly used for the same form submission, then?  POST and PUT seem the right verbs for a form submission that changes state on the server (Add a comment to a blog), and GET seems the right verb for a form submission that is requesting specific information from the server (like using a search engine to find pages that match a set of keywords).  </p>
<p>This would have the side-effect of causing updates of bank account or social security information to be POSTs or PUTs (which don&#8217;t use the query-string).  The only issues we would ever have would be:</p>
<p>-The user is trying to GET a resource from the server using some secure field (like a social security number)<br />
-The developer has used GET to do form submissions involving creates or updates</p>
<p>Are there actually valid use-cases for either?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Ulf		</title>
		<link>https://www.selikoff.net/2010/05/02/get-vs-post-and-url-security/comment-page-1/#comment-2433</link>

		<dc:creator><![CDATA[Ulf]]></dc:creator>
		<pubDate>Mon, 03 May 2010 07:36:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.selikoff.net/?p=1952#comment-2433</guid>

					<description><![CDATA[Just in case the connection isn&#039;t clear between sensitive URLs and links from them to external sites: the URL of the page containing the link is sent via the HTTP Referer header. While some browsers -like Firefox- have an obscure setting to suppress this header, few users will be aware of its existence or significance. (And some web apps actually rely on that header being sent, although I&#039;d say those apps are broken since the HTTP spec does not require it.)]]></description>
			<content:encoded><![CDATA[<p>Just in case the connection isn&#8217;t clear between sensitive URLs and links from them to external sites: the URL of the page containing the link is sent via the HTTP Referer header. While some browsers -like Firefox- have an obscure setting to suppress this header, few users will be aware of its existence or significance. (And some web apps actually rely on that header being sent, although I&#8217;d say those apps are broken since the HTTP spec does not require it.)</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
