Why does the Flash Player Have Such Crappy HTTP Support?

I’ve found myself enjoying working with Adobe Flex. Flex does a lot of things really well, except its support of the HTTP protocol. Here’s a few things folks don’t know about the Flash Players HTTP support:

  • It only support GET and POST methods. In order to use other methods such as DELETE and PUT, you have to the proxy service in Live Cycle Data Services. Lame!
  • The Flash Player can’t read entity responses if a service returns a response code higher than 200. The LDS proxy gets around this limitation by forcing the response to a 200 status and returning the fault entity. Without LDS, there’s no way to get the response entity. Still lame.
  • You are extremely limited to the number of header values you can set. The following header values cannot be used by the URLRequestHeader class: Accept-Charset, Accept-Encoding, Accept-Ranges, Age, Allow, Allowed, Connection, Content-Length, Content-Location, Content-Range, Date, Delete, ETag, Expect, Get, Host, Keep-Alive, Last-Modified, Location, Max-Forwards, Options, Post, Proxy-Authenticate, Proxy-Authorization, Public, Put, Range, Referer, Retry-After, Server, TE, Trace, Trailer, Transfer-Encoding, Upgrade, URI, User-Agent, Vary, Via, Warning, WWW-Authenticate, x-flash-version.

These features are extremely limiting for an RIA platform. It’s not always easy to try an sell RIA solution that is based on a platform crippled by limited networking support. I sincerely hope that future incarnations can get around these issues by providing a real HTTP implementation.

Why does the Flash Player Have Such Crappy HTTP Support?

Some Thoughts on Securing Web Resources

Lately I’ve been trying to figure some figure out some new ways to define declarative security constraints to web resources. Here’s the a use case that popped into my head a while back: suppose you have a service to access a persons information on a social networking site such as:


http://mysocialnetwork.foo/people/12345

This service offers two levels of membership: free and paid subscriptions. The free model only allows the caller to access a limited subset of information about user 12345, but a paid subscriber would have access to the complete record. So same URI, but a different resource depending on the authorization credentials of the caller.

Declarative security in the servlet API only allows you apply constraints to a single URI. So with the servelt API, you’d have to create to separate URIs in order to separate the functionality for free and paid users. By creating multiple URIs for different service tiers, the user would have to change the the URIs in their calling code if they upgraded from a free to paid subscriber.

To get around this, I’m thinking that a web resource could leverage the security annotations from JSR-250 so that you could write a PersonResource like so:

@UriTemplate("/people")
class PeopleResource {

   @UriTemplate("{id}")
   @RolesAllowed({"paidSubscriber"})
   @SecureTransport
   PersonResource getPaidPersonResource (@UriParam("id) String id) {
     return PaidPersonResource(id);
   }

   @UriTemplate("{id}")
   @RolesAllowed({"basic"})
   PersonResource getCheapSkatePersonResource( UriParam("id) String id) {
     return CheapSkatePersonResource (id);
   }
}

In this instance, the framework would invoke the method that the user is authorized for. If the user was a paid subscriber, they’d invoke the resource method that returns a PaidPersonResource. Additionally, because the PaidPersonResource may contain sensitive information, it must be accessed over SSL. The @SecureTransport annotation will redirect the caller to the same URI, but using a secure port.

Of course, if declarative security isn’t you cup of tea, then you can alway manage it yourself:

@UriTemplate("/people")
class PeopleResource {

   @HttpContext SecurityContext securityContext;

   @UriTemplate("{id}")
   PersonResource getPerson(@UriParam("id) String id) {
     if (securityContext.isUserInRole("paidSubscriber")) {
       if(securityContext.isTransportSecure()) {
          return PaidPersonResource(id);
       }else {
          //-- Handle your else condition
       }

     } else {
       return FreePersonResource(id);
     }
   }
}

Since JSR-311 is not exclusive to a servlet container, the SecurityContext would be a generalized injectable interface that provides access to security related information. This would make access to security details consistent across implementations regardless of whether or not you’re using a servlet container or not.

Please keep in mind that this is just an idea that I’m throwing around and it’s nothing official yet.

Some Thoughts on Securing Web Resources

The State of RESTEasy

It’s been a while since my last post and even longer since I blogged about RESTEasy. Or better yet, since I committed a change to the RESTEasy code base. This might have lead some to believe that RESTEasy has been abandoned and will cease to exist. Since I have been getting inquiries from friends as to what is going on with RESTEasy, I figured I should probably make a post about. So while the project is not being abandoned, the core API is definitely being rethought.

I have been doing some work on JSR-311 which is a JSR that will help formalize how to create a RESTful web service in Java. The ideas in RESTEasy and JSR-311 were similar, but the implementations are completely different. With that said, it didn’t make much sense to proceed down the path I was going and so I had decided to temporarily suspend development on RESTEasy until JSR-311 is closer to finalization.

I’ll be posting a few more ideas over the next few months, but development of RESTEasy probably won’t pick up again until late November-ish. So not dead, just on hold for a few.

The State of RESTEasy