archive-com.com » COM » B » BENRAMSEY.COM

Total: 425

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Specifying rev="canonical" With HTTP, by Ben Ramsey
    canonical rel alternate shorter href http brtny me 382 And all without any special WordPress plugin For the ID I m simply using the WordPress post ID which means that if I change to another blogging tool in the future I will need to maintain my indexes Note that I ve implemented it with both the popular rev canonical and my preferred rel alternate shorter Chris Shiflett posts about the need for an HTTP header I think this is also a good idea for the same reasons he mentions Chris s original recommendation is for an X Rev Canonical header but Stephen Paul Weber mentions the Link header I think the Link header is the right way to go about this since it offers an HTTP analogue of the HTML link element Link is an IETF proposal by Mark Nottingham that is still in the Internet Draft stage going through the IETF process for standardization but it s current which is a good thing If the community chooses to use it though it s interesting to note that that it states bq Applications that don t merit a registered relation type may use an extension relation type An extension relation type is a URI that when dereferenced SHOULD yield a document describing that relation type This means that one should not simply put canonical as the value for rev Instead it would be more proper to use something like http revcanonical appspot com canonical until canonical is accepted as a registered IANA relation type I wonder if the same is technically true of the rel and rev attributes in HTML For now I ve decided to cover all bases in my HTTP headers as well and you can see this by making a HEAD request to any blog post on

    Original URL path: https://benramsey.com/blog/2009/04/specifying-revcanonical-with-http/ (2016-04-26)
    Open archived version from archive


  • Summarizing My rev="canonical" Argument, by Ben Ramsey
    is a better way What I would like to focus on is why people seem to think rev canonical is better than rel alternate shorter Is it If so why Consider this obviously fictional and tongue in cheek dialogue between a client and a requested resource Hi Resource How s it shakin today I like what you have to offer but what s this rev canonical link you have Am I not already requesting your canonical URL Oh Hi Client Yes this is my canonical URL but that s another URL that refers to my canonical URL Why would I want to know what other URLs refer to your canonical one Is not the point of having a canonical URL that the other URLs don t matter Besides they all point here anyway True but that s a shorter URL that you might want to use instead of my canonical one Well how was I supposed to know that All it tells me is that it s another URL that points to your canonical one It s implied Implied Yeah A community agreed that rev canonical would mean that the URL identified by the href is a shorter form for my canonical one Why didn t they just make it explicit with something like a rel alternate shorter attribute instead being ambiguous about it And that s the crux of my argument A couple of other notes On my previous post Matt Cutts makes an excellent point about the danger in allowing documents to claim canonical ness over other URLs But if we do like Google did with rel canonical and restrict rev canonical to specify only URLs that are in the same domain as the canonical one then we lose the value of being able to specify shorter domains

    Original URL path: https://benramsey.com/blog/2009/04/summarizing-my-revcanonical-argument/ (2016-04-26)
    Open archived version from archive

  • A rev="canonical" Rebuttal, by Ben Ramsey
    document am the canonical URL for that URL over there the one specified in the href of the link tag What I think will happen though is that people will misunderstand this as previous usage of rev has shown This misunderstanding could lead to the following improper implementations Let s say for example that the current document s canonical URL is http example org 2009 04 10 a rebuttal for rev canonical A shortened form might be http example org revcanonical Knowing this the correct implementation for rev canonical would be link rev canonical href http example org revcanonical Thus when a client reads http example org 2009 04 10 a rebuttal for rev canonical it sees this link and understands that the current URL is the canonical URL for http example org revcanonical I foresee that implementers could easily misunderstand this and implement it like this link rev canonical href http example org 2009 04 10 a rebuttal for rev canonical In this case the link is self referential and the value of rev canonical is lost since no short form is specified However this won t lead to any problems since the default URL for a document not containing rev canonical is the original URL according to RevCanonical What will lead to problems is when people misunderstand rev thinking it to mean rel after all rev isn t in the HTML 5 spec so maybe rel will work or so the thinking may go so they implement it like this link rel canonical href http example org revcanonical This means something entirely different This tells Google and maybe other search engines that the canonical URL of the current document is the value of the href It is the inverse of rev canonical This might not lead to a problem quite as drastic as the linkrot apocalypse but it might lead to inaccurate URLs being stored in search engines and could negatively affect your SEO Finally earlier I said that rev canonical means I am the canonical URL for that URL over there In this case that URL over there just happens to be a shorter one but semantically that s not what rev canonical means and here is another problem with this approach A canonical URL is just that canonical It is the primary URL used to refer to the resource All other URLs referring to the resource are secondary and unimportant except insomuch as they direct us to the primary URL In fact there could be infinite secondary URLs that direct clients to the canonical one By specifying rev canonical you assign importance to the link identified by the href but you don t express why it is important except to say that it is another URL that points to this canonical one In fact you could have hundreds of rev canonical links for any particular document How would an implementer choose the proper one to use as the short URL This is why I think better

    Original URL path: https://benramsey.com/blog/2009/04/a-revcanonical-rebuttal/ (2016-04-26)
    Open archived version from archive

  • OAuth IETF Working Group, by Ben Ramsey
    a starting point for the working group OAuth 1 0 draft hammer oauth 00 txt is used and the available extension points are going to be utilized The WG will profile OAuth 1 0 in a way that produces a specification that is a backwards compatible profile i e any OAuth 1 0 and the specification produced by this group must support a basic set of features to guarantee interoperability I ve signed up for the mailing list if for nothing else than to follow along and see how the IETF process takes a document from Internet Draft all the way to RFC but maybe I ll find something of value to contribute as well We ll see There s already been some discussion on the list concerning the use of OAuth on protocols other than HTTP such as XMPP Since OAuth 1 0 explicitly references HTTP the working group has added provisions to consider the ability to address broader use cases than may be contemplated by the original authors So the final RFC may address uses of OAuth beyond HTTP which I find interesting Eran Hammer Lahav is soliciting feedback from those who have read the OAuth 1 0

    Original URL path: https://benramsey.com/blog/2009/02/oauth-ietf-working-group/ (2016-04-26)
    Open archived version from archive

  • HTTP Status: 100 Continue Corrections, by Ben Ramsey
    100 continue is to give the server a chance to give an error to the client before it sends the request body rather than after If doing that required that all of those detailed 4xx 5xx errors were turned into an opaque 417 and useless plain language errors in the body it would be useless Glenn is correct What I missed in Section 14 20 of RFC 2616 was this The server MUST respond with a 417 Expectation Failed status if any of the expectations cannot be met or if there are other problems with the request some other 4xx status Furthermore Section 8 2 3 states Upon receiving a request which includes an Expect request header field with the 100 continue expectation an origin server MUST either respond with 100 Continue status and continue to read from the input stream or respond with a final status code Emphasis added My faulty logic occurred because I was using the look before you leap LBYL concept presented in RESTful Web Services in which Ruby and Richardson propose that a request including the Expect header can be made to determine whether the server will fulfill the request given the headers present They state if the answer is no the server sends a status code of 417 Expectation Failed The answer might be no because 500 MB is just too big pg 250 According to RFC 2616 this is wrong If the server does not support the 100 continue expectation then and only then should it send back the 417 Expectation Failed response Otherwise if for example the Content Length is too big for the server to fulfill the response then it would respond with a final status code such as 413 Request Entity Too Large You may still use this approach to

    Original URL path: https://benramsey.com/blog/2009/02/http-status-100-continue-corrections/ (2016-04-26)
    Open archived version from archive

  • HTTP Status: 100 Continue, by Ben Ramsey
    specifically in a RESTful manner Consider these Ben s HTTP Status Codes Best Practices I won t be covering these status codes in any particular order However the first code up is 100 Continue merely because I ve been thinking about it lately The 100 Continue status code is an informational response that tells the client application it can continue sending the request In short the client can make an abbreviated request of the service to check whether or not it should continue making the full request The service can then respond either yes 100 Continue or no 417 Expectation Failed with an explanation of why not In RESTful Web Services Richardson and Ruby refer to this as a look before you leap LBYL request This is helpful in situations where the client might want to post or put a very large file to the service but wants to ensure that the service will accept it before actually sending the file Consider the following request POST content videos HTTP 1 1 Host media example org Content Type video mp4 Content Length 105910000 Authorization Basic bWFkZTp5b3VfbG9vaw Expect 100 continue In this case the client is attempting to post an MPEG 4 video that is 101MB The client sends this request to your service without the video in the body and it includes the Expect 100 continue header Let s say your service limits uploads to 100MB In that case you would return a 417 Expectation Failed including a reason for the failure in the body of the response By now you can probably see how this can be extended to apply to any of the other headers For example a client can try a POST or a PUT request first just to see if its authorization succeeds If it does your

    Original URL path: https://benramsey.com/blog/2008/04/http-status-100-continue/ (2016-04-26)
    Open archived version from archive

  • Book Review: RESTful PHP, by Ben Ramsey
    in the book with the author explaining the principles of REST by showing how the services examined are or are not RESTful In addition the book devotes very little space to actually describing the principles of the REST architectural style Instead there is only a small section in the first chapter that lists some of the principles of REST in a bullet list I say some because the book fails to mention the principles of client server caching layering and code on demand Of particular importance to me are the principles of caching and layering because I think these make for the most compelling arguments for using the REST style Later when the book tries to make a case for the need for RESTful web services it talks only about the need for web services and why PHP programmers need to know how to consume REST services rather than actually explaining why REST itself is important While my criticism of the author s lack of focus on defining and explaining REST is harsh I will return again to my point about the practically of the book s examples It is filled to the brim with working code examples that show how to consume Flickr BBC News Yahoo Maps and other web services and he discusses many tools to use as HTTP clients in PHP from curl to Zend Rest Client He also goes into much detail explaining how to design and implement RESTful web services using a fictional library service as an example In truth the real focus on the book isn t on REST but on the resource oriented architecture and to that end he does offer some good discussion even covering such topics important to the community as PUT vs POST and URL design nuances of design that

    Original URL path: https://benramsey.com/blog/2009/01/book-review-restful-php/ (2016-04-26)
    Open archived version from archive

  • HTTP Status: Client Errors, by Ben Ramsey
    let s assume that the server doesn t allow POST requests to the content videos URI If this is the case then the server should return a 405 Method Not Allowed status code in response to this request This is a condition that we could have checked for with the LBYL request prior to sending the full 105 910 000 bytes of the video thus saving bandwidth client resources and server resources HTTP 1 1 405 Method Not Allowed Date Wed 28 Jan 2009 03 04 25 GMT Allow GET HEAD In addition to the 405 Method Not Allowed status according to RFC 2616 the server must included an Allow header listing the valid methods for the requested resource Sending the Allow header in response to HEAD requests and all requests for that matter can also help inform clients of acceptable methods If the server does allow POST requests at this URI but we fail to send the Authorization header with the request then the server should respond with a 401 Unauthorized status telling the client to resend the request with proper authorization The server must include a WWW Authenticate header in this response to indicate the expected authorization scheme If the request however does include the Authorization header as illustrated in the example but the authentication fails for whatever reason then the server should respond with a 403 Forbidden status and a description with the reason for the failure in the response body If the request doesn t include the Content Length header then you might want the server to respond with a 411 Length Required status Requiring the length and comparing it to the length of the actual request body is a good way to determine whether there was any loss of data However if the integrity of data is a concern you might want to require clients to include the Content MD5 header in the request Since there is no status code to indicate Content MD5 as a requirement simply return a 400 Bad Request status stating your requirement of the Content MD5 header in the response body The 400 Bad Request status code literally means that the request could not be understood by the server due to malformed syntax but it is a generic enough response that it can be used for a variety of other client errors not covered by the other 4xx series status codes For example I have used 400 Bad Request as a way to indicate data validation failures in POST and PUT requests If the full request reaches the server but the server determines that the 105 910 000 bytes of the video is beyond the acceptable limit maybe we want to limit users to 50MB uploads then respond with 413 Request Entity Too Large because the request body is larger than the server is willing to process Again the client could avoid this by using a LBYL request Likewise if the server doesn t want to support the video mp4

    Original URL path: https://benramsey.com/blog/2009/01/http-status-client-errors/ (2016-04-26)
    Open archived version from archive



  •