The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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.

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: http://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

http://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2019 by Sean Conner. All Rights Reserved.