Welcome Guest Search | Active Topics | Sign In | Register

Feature Request: Internal object handler Options
Simon Scheurer
Posted: Monday, July 8, 2013 8:13:54 AM
Rank: Advanced Member
Groups: Member

Joined: 5/14/2013
Posts: 45
I already discussed this topic with Jack by e-mail but still will add it as a feature request in the forum (for HtmlToPdf).

It's about overriding the normal HTTP-Handler for object retrieval. I.e. we are serving objects internally from an archive system. What we would like to achieve is to have a boxed rendition service that does not need an IIS installation (or some other webserver installation). Basically we would like to omit the HTTP-Stack.

What we would like to be able is to do something like:

Code: C#
EOHttpResponse HandleRequest(EOHttpRequest) {
   ...
   return result;
}

HtmlToPdfOptions.HttpHandler = HandleRequest;


with EOHttpRequest and EOHttpResponse being simple objects that contain all relevant information to feed the browser (HTTP Header, HTTP Body).
Instead of retrieving objects over HTTP EO would then simply use the HandleRequest method provided to gather the page objects (css, jpg, etc.). This would allow for completely webserver-less processing of HTML-Renditions.

In our case where we control the serving application as well as the renditioner process we have much more control over the whole process. This helps for verification (if everything went well - very important in litigation scenarios), faster processing (no HTTP stack/webserver involved, less overhead), better control (number of database connections use, filtering of irrelevant requests, etc.).
eo_support
Posted: Monday, July 8, 2013 3:28:08 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

The idea of having custom protocol sounds like it can eliminate HTTP stack but in reality you can not discard those because Web page and HTTP works very closely with each other. A lot of HTTP headers MUST be property rendered no matter the underlying protocol is HTTP or is a custom protocol. For example, in order for the browser to correctly render image, you must set the Content-Type HTTP header correctly. In order for session states to work correctly, cookies must be properly handled. This makes it impossible to get rid of the HTTP stack. Adding an additional layer of "filters" is technically possible, but HTTP has to be always there. If HTTP has to be there, then nobody serves HTTP better/more efficient than a Web server. So the logical solution is still to have a web server.

Thanks!
Simon Scheurer
Posted: Monday, July 8, 2013 3:58:17 PM
Rank: Advanced Member
Groups: Member

Joined: 5/14/2013
Posts: 45
Well, we have the full HTTP Stack anyway. We have all headers (we produce them by ourselves also when serving over the webserver). There is still a transport stack involved and need for a web-server that a protocol handler would eliminate.

So in our case the logical solution is not to have a web-server. The way our application works we would have huge benefits of not having to go over the additional web-server layer. We use custom headers currently to transport information to the web-server (basically internal session) and need additional pre and post requests for verification. Additionally database control is more difficult as we have to deal with several processes (rendition part and webserver part). "Rebuilding" HTTP-Stack is very easy and we do that anyway. In our case it is definitely not the efficient way to servce it using a webserver. And it makes deployment more clumsy (at our customers site) by having to setup either IIS or use some embedded web-server-component. Just being able to eliminate that unnecessary layer is a huge benefit for us.

I'll be happy to explain in more detail what we are doing. Then it is easier to understand. We would even be willing to pay something extra for this feature if it can be made.

Best regards,

Simon
eo_support
Posted: Monday, July 8, 2013 4:04:47 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

We really do not see the benefit of this. Since you are handling all the HTTP headers any way, all you have to do is to create a socket server that listens on whatever port you choose, then when a request arrives, call your custom handler to actually do the work. It will be probably less than 100 lines of code on your end. TCP/IP on the same machine almost always goes through memory, which is by itself already very efficient. Basically you will be implementing your own mini-Web server.

Thanks


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.