Announcement

Collapse
No announcement yet.

new window remains open when sending newmail using proxy

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • new window remains open when sending newmail using proxy

    OX6.18.1
    Firefox 3.6.13
    apache version seems to be irrelevant, e.g. 2.2.15

    reverse proxy config is measwhile reduced down to:

    ProxyPass /ox/ http://oxserver/ox6/
    ProxyPassReverse /ox/ http://oxserver/

    ProxyPass /ajax/ http://oxserver/ajax/
    ProxyPassReverse /ajax/ http://oxserver/ajax/

    ProxyPass /servlet/ http://oxserver/servlet/
    ProxyPassReverse /servlet/ http://oxserver/servlet/

    This happens only when using the ox gui from behind an apache reverse proxy, direct
    way everything correct. I open new mail and send it. The new mail window gets closed and mail is realy sent, but in the same moment a new windows pops up with following address:

    http://my.proxy/ajax/mail?action=new...39f99055b87d0c

    which is basically the POST send request sent before which gets even the HTTP 200 OK reply from ox ! Looking at the tcpdump and cannot understand it. The only little difference is within the 200 OK reply:

    direct:
    HTTP/1.1 200 OK
    Date: Thu, 20 Jan 2011 23:23:50 GMT
    Expires: Sat, 06 May 1995 12:00:00 GMT,Sat, 06 May 1995 12:00:00 GMT,Sat, 06 May 1995 12:00:00 GMT
    Content-Type: text/html; charset=UTF-8
    Pragma: no-cache,no-cache,no-cache
    Cache-Control: no-store, no-cache, must-revalidate,post-check=0, pre-check=0,no-store, no-cache, must-revalidate,post-check=0, pre-check=0,no-store, no-cache, must-revalidate,post-check=0, pre-check=0
    Vary: Accept-Encoding
    Content-Encoding: gzip
    Content-Length: 259
    Keep-Alive: timeout=15, max=100

    and proxied:
    HTTP/1.1 200 OK
    Date: Thu, 20 Jan 2011 23:18:13 GMT
    Expires: Sat, 06 May 1995 12:00:00 GMT
    Content-Type: text/html; charset=UTF-8
    Pragma: no-cache,no-cache,no-cache
    Cache-Control: no-store, no-cache, must-revalidate,post-check=0, pre-check=0,no-store, no-cache, must-revalidate,post-check=0, pre-check=0,no-store, no-cache, must-revalidate,post-check=0, pre-check=0
    Vary: Accept-Encoding
    Content-Encoding: gzip
    Content-Length: 258
    Keep-Alive: timeout=15, max=100

    The lenght seems to be due to differently zipped trailing contents inside but the gzipped content is always the same:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <script type="text/javascript">(parent.callback_new || window.opener && window.opener.callback_new)({"data":"default0/Sent/269"})</script>

    Martin, any ideas ?

  • #2
    Hi,

    i guess we should check that at our side. Can you open a bug report at https://bugs.open-xchange.com/ and describe the proxy setup?

    Thanks!

    Comment


    • #3
      Originally posted by Martin Braun View Post
      Hi,

      i guess we should check that at our side. Can you open a bug report at https://bugs.open-xchange.com/ and describe the proxy setup?

      Thanks!
      Hmm, ok, maybe another bug... But I'll do some more testing before. When looking into Ajax part, that window opens on Form submission. And that form belongs to html code of the newmail window received before. And that might be mangled by proxy in some way. I have to look a bit backwards first...

      Comment


      • #4
        Ok, I just looked into it once more. This problem arises when proxy-html is being deployed (which is basically a good idea to sanitize/cleanup html traffic passing the proxy.). The trouble is that OX announces in newMail.html the document type:

        <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"

        however, it includes there some at least deprecated elements/attributes like the 'form target="mailSendCB"' and the target hidden iframe used to submit to form for new mail. But these elements are allowed only in legacy transitional doc type, so proxy-html will remove this stuff.

        The question now is, why are these deprecated elements used - is there no other, cleaner solution for ajax form submission or is this necessary to support some broken legacy browsers like IE ?

        For now, the workaround seem to be to set "ProxyHTMLDocType HTML legacy" in proxy config for the OX Location.

        Comment


        • #5
          For now, the workaround seem to be to set "ProxyHTMLDocType HTML legacy" in proxy config for the OX Location.
          which unfortunatelly breaks the font size (style sheets ?). So not really a workaround.

          Comment


          • #6
            The OX HTML does not contain any absolute links, so I see no reason to touch the content. Why do you want to use mod_proxy_html?

            Comment


            • #7
              We use proxy_html by default on every stream passing the external gateway. It is a kind of security measure - to sanitize the code and remove on the fly any extra stuff like comments.

              The trouble is, OX header annouces a document type which is not really true, I think this should be cleaned up to conform the the W3C standards. Is there really no cleaner solution possible than this ugly iframe workaround ?

              Comment


              • #8
                Hi,

                well you could put that information to a bug report and we check what can be done here. Thanks for reporting

                Greetings

                Comment


                • #9
                  Originally posted by sam View Post
                  ... and remove on the fly any extra stuff like comments.
                  This one will break the UI, no matter what DOCTYPE we use.

                  Comment


                  • #10
                    Originally posted by Viktor Pracht View Post
                    This one will break the UI, no matter what DOCTYPE we use.
                    Uhm, yes, but the point is not to change/fake the doctype but not to use deprecated elements like "iframe" or "frame target" at all.

                    Comment


                    • #11
                      I think you didn't understand. Removing comments will break the UI in Internet Explorer, because it evaluates at least one of them (that I know of). This means, leaving mod_proxy_http enabled will break the UI, even if we work around the DOCTYPE problem.

                      And BTW, neither the iframe element nor the target attribute are deprecated. They are the only possibility to solve the exact problem you are complaining about: controlling where to open new documents. Removing the target attribute from XHTML and strict HTML was a stupid idea, and it's back in HTML 5.

                      Comment


                      • #12
                        Yeah, I indeed did not understand. That was simply beyond my imagination that comments are needed to make UI work in IE. Bah, WTF. Anyway, who cares about Internet Explorer nowadays ?

                        On the other hand, if those iframe & target cannot be avoided, the only way for me is to patch the proxy-html (which would be simple, but it goes unfortunately deeper into the libxml2 parser). Anyway, thanks for giving me this deeper insight.

                        Comment

                        Working...
                        X