Thursday, August 23, 2001
They're all on crack
Mark has written an embeded web server he's releasing as open source Real Soon Now, and a friend of ours, Andrew is writing up the documentation. He sent a question to Mark, who sent it on to me:
[The webserver] has a constant HTTPD_RESP_MOVED_TEMP set to 302.
RFC 2616 says that 302 means “Found”. 307 would be a “temporary redirect”, and 303 would be “see other”.
I don't see a clear correspondence here‥ can you explain your reasoning?
Under an earlier draft of the HTTP 1.1 protocol, a server response of 302 meant that the object in question is temporarily not available at the given URI, but elsewhere. In the newer draft it means something different, and a response code of 307 means the object in question is temporarily not available at the given URI, but elsewhere:
10.3.3 302 Found
The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
§10.3.3 of RFC-2616
10.3.8 307 Temporary Redirect The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI. If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
§ 10.3.8 of RFC-2616
Okay, so I couldn't really tell the difference myself (except for the change of “might” to “MAY” in the first paragraph, and the addtional verbiage in the second paragraph, and the note added in § 10.3.3, there isn't any difference (and the additional text doesn't really clarify anything).
I wrote back:
They're all on crack.
My response: If you get a “POST <spec> HTTP/1.1” and you need to redirect the user to a temporary URI, send back a 307 with enough information to re-POST the information at the new URI, otherwise, just send back a 302.
The Blogger API via XML-RPC over HTTP on top of TCP/IP
I'm beginning to see what all this XML-RPC is all about. It's a more formal specification of the WWW CGI because I guess reading the HTML source and finding out the input fields for a form, then URLencode the data to call the external program is just too much work for some people.
I've done work before, using, I guess, a form of CGI-RPC to implement a program that does an Internet search using the major search engines to gather the results. And yes, it's was (and still is to a degree) a pain because each engine basically has a different calling convention (or API if you will). XML-RPC seems to be a way to standardize on an API, such as a search engine API.
Not that it's a bad idea, but XML seems a bit overbloated for me. But I guess for the type of services being done, like the Blogger API it's not that bad of overhead. And just think, if I can implement the Blogger XML-RPC API, not only can I claim alphabet-soup compliancy, but I can use several tools to write my blogger with, not just using a web form or email.
