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.
-
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. -
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.Leave a comment:
-
This one will break the UI, no matter what DOCTYPE we use.Originally posted by sam View PostLeave a comment:
-
Hi,
well you could put that information to a bug report and we check what can be done here. Thanks for reporting
GreetingsLeave a comment:
-
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 ?Leave a comment:
-
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?Leave a comment:
-
which unfortunatelly breaks the font size (style sheets ?). So not really a workaround.For now, the workaround seem to be to set "ProxyHTMLDocType HTML legacy" in proxy config for the OX Location.Leave a comment:
-
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.Leave a comment:
-
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...Originally posted by Martin Braun View PostLeave a comment:
-
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!Leave a comment:
-
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:
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 ?
Leave a comment: