eCAP

Request Satisfaction splash screen problem

Asked by WorkingMan

So I am trying to show an error page that can redirect user to original request or do nothing (accept blocked state).

The problem are the following:

1) I tried to get URI in REQMOD but firstLine() is always NULL (followed #1576 for getting URI)
2) I then tried URI redirect in RESPMOD. I can see the URI but with problems.
2a) if I use blockVirgin() and deny_info, everything is great except I can't get clean original request URI. It's usually a bunch of weird stuff before and after the real URI. I am not sure what's going on (I tried http://example.com?url=%u (or %s)). It's so bad request never ends from the log original URI is way too long (multiple lines) and with spaces, only tiny part of it is the original URI.
2b) if I use hostx.virgin().clone(), requestLine->uri(newURI), useAdapted(adapted); even had statusCode(302) at some point, sequence and the request will fail in the browser (in firefox it's connection reset; in chrome it's target machine (ie: squid) actively refused it). So I was hoping by formatting the redirect URI in the adapter I can pass the correct original URI but it seems I am doing something wrong here.

I like 2a because it's simple but can't get proper original URI. I don't mind 2b but it's not working (tried making hostx = 0 so it's the last call doesn't make a difference). Also I am puzzled as why I can't handle any of this in the REQMOD (ie: at request time before hitting the server).

code for 2b:
Adapter::Xaction::start(){

     libecap::Area uri;
    typedef const libecap::RequestLine *CLRLP;
    if (CLRLP requestLine = dynamic_cast<CLRLP>(&hostx->virgin().firstLine()))
            uri = requestLine->uri();
    else
    if (CLRLP requestLine = dynamic_cast<CLRLP>(&hostx->cause().firstLine()))
            uri = requestLine->uri();

    //do header checks here

   libecap::host::Xaction *x = hostx;
   Must(x);
   xhost = 0;

   if(!Allowed())
   {
      //LRLP is non-const version of CLRLP
       LRLP requestLine = dynamic_cast<LRLP>(&hostx->cause().firstLine();
       libecap::shared_ptr<libecap::Message> adapted = hostx->virgin().clone();
       libecap::Area newURI ("http://example.com?url=test.com");
       requestLine.uri(newURI);
       x->useAdapted(adapted);
   }
   sendingAb = opNever;
   x->useVirgin();
}

Thanks

Question information

Language:
English Edit question
Status:
Answered
For:
eCAP Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
WorkingMan (signup-mail2002) said : 		#1

After some digging I solved the issue. What was happening was after deny_info redirects to the splash/error page ecap adapter will receive the new URL. So in the old code It would just process that URL which I guess causing corruption since URL will get bigger and corrupt.

I realized this was the issue after adding a lot of verbose syslog() calls. So all I did was if I am receiving the redirect page (check using strncmp to check first X character) I will call useVirgin() and make hostx = 0 so it doesn't get called again. This allowed the redirect page to finish loading. I think this is the same issue as url_rewrite_program has but I prefer this method much better.

I am still not getting the URI in request mode but that's ok. In the response first URI is always the original request URI. If you call blockVirgin() on it along with deny_info you simply stop the client from loading any further content for the original URI so the overhead is very small. If for some reason you don't break the body loading flow it will finish loading every single resources from the page and that wouldn't be the most efficient way if you simply want to do blocking based on the URI.

Creating your own page in the adapter is not documented enough (no working example) for me to try successfully. I will need to try more complicated URI to see if deny_info works. If the above description is accurate it should work for any case (I used %u for getting the original URL in the deny_info: deny_info 302:http://example.com?url=%u eRespmod, 302 might not be required)

In the case of https SQUID is hogging high CPU (>95%) and request does not finish so I can't say the above works everywhere. Unless I need to do some kind of handling for CONNECT.

Revision history for this message
Alex Rousskov (rousskov) said : 		#2

Thank you for a detailed update. It looks like you are making progress although there are still many unusual problems. If you have any specific questions, please ask.

Can you help with this problem?

Provide an answer of your own, or ask WorkingMan for more information if necessary.

To post a message you must log in.