Re: Proxy Error, posted by Stefan Ritt on Wed Jan 13 11:34:51 2010
|
> I only got one email in response to the second entry of this thread, no email was received after the edit of the entry. The
> next email received was due to the third entry of this thread.
Ok, let me try (sorry to all the users who subscribe to this forum for pestering you...):
1st reply to your entry.
1st reply edited. |
|
Re: Proxy Error, posted by David Pilgram on Wed Jan 13 11:19:59 2010
|
> > > Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
> > > without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
> > > it is connected with the html coding?
> > Hi Stefan,
> >
> > I now cannot even reply to you in the message id thread; I keep getting:
> >
> > Proxy Error
> >
> > The proxy server received an invalid response from an upstream server.
> > The proxy server could not handle the request POST /elogs/Forum/.
> >
> > Reason: Error reading from remote server
> >
> > Apache/2.2.3 (Scientific Linux) Server at midas.psi.ch Port 443
> >
> > It is, I think, something to do with the html coding (as I normally use plain, I don't come across this as an issue).
> >
> > However, in the cause of the experiment, I will submit this entry, then go back and edit it, and if I don't get
> > Proxy Error, then that certainly will be something to do with the html coding.
> >
> > And this is an extra edited line - if you see this, I got past the proxy error issue this time. But did you get two
> > emails?
>
> That is interesting. I can make 1 (one) submission to a thread which uses html coding, then I get hit by proxy errors.
> But I can edit, play around or whatever if it is in plain coding. Yet to see how many emails were generated...
Hi Stefan,
I only got one email in response to the second entry of this thread, no email was received after the edit of the entry. The
next email received was due to the third entry of this thread. |
|
Re: Proxy Error, posted by David Pilgram on Wed Jan 13 11:17:39 2010
|
> > Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
> > without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
> > it is connected with the html coding?
> Hi Stefan,
>
> I now cannot even reply to you in the message id thread; I keep getting:
>
> Proxy Error
>
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request POST /elogs/Forum/.
>
> Reason: Error reading from remote server
>
> Apache/2.2.3 (Scientific Linux) Server at midas.psi.ch Port 443
>
> It is, I think, something to do with the html coding (as I normally use plain, I don't come across this as an issue).
>
> However, in the cause of the experiment, I will submit this entry, then go back and edit it, and if I don't get
> Proxy Error, then that certainly will be something to do with the html coding.
>
> And this is an extra edited line - if you see this, I got past the proxy error issue this time. But did you get two
> emails?
That is interesting. I can make 1 (one) submission to a thread which uses html coding, then I get hit by proxy errors.
But I can edit, play around or whatever if it is in plain coding. Yet to see how many emails were generated... |
|
Re: Proxy Error, posted by David Pilgram on Wed Jan 13 11:15:10 2010
|
> Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
> without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
> it is connected with the html coding?
Hi Stefan,
I now cannot even reply to you in the message id thread; I keep getting:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /elogs/Forum/.
Reason: Error reading from remote server
Apache/2.2.3 (Scientific Linux) Server at midas.psi.ch Port 443
It is, I think, something to do with the html coding (as I normally use plain, I don't come across this as an issue).
However, in the cause of the experiment, I will submit this entry, then go back and edit it, and if I don't get
Proxy Error, then that certainly will be something to do with the html coding.
And this is an extra edited line - if you see this, I got past the proxy error issue this time. But did you get two
emails? |
Proxy Error, posted by David Pilgram on Wed Jan 13 10:59:44 2010
|
Having made one entry in the thread about message ID, I could neither edit the entry or add an additional reply
without getting "Proxy Error" messages. I've had this trouble on this forum before, a long time ago. Perhaps
it is connected with the html coding? |
|
Re: Problems zooming elog pages in Internet Explorer - a possible fix, posted by Stefan Ritt on Fri Nov 13 15:54:21 2009
|
| Richard Stamper wrote: |
|
Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -). This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.
The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen. If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them. The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".
The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property. The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.
Adding
span {
display: inline-block;
}
to default.css (e.g. just after the default style definition for the "td" element) and adding
display: inline-block;
to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox. I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.
Cheers,
Richard Stamper
|
I just tried with IE8 (don't have IE7 installed any more), and it looked to me like this has been fixed there. So this will get less a problem in the future. If people are stuck to IE7, they can made your modification themselves in the CSS file, so I guess I won't change the distribution for the moment.
|
Problems zooming elog pages in Internet Explorer - a possible fix, posted by Richard Stamper on Wed Nov 4 00:58:00 2009
|
Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -). This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.
The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen. If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them. The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".
The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property. The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.
Adding
span {
display: inline-block;
}
to default.css (e.g. just after the default style definition for the "td" element) and adding
display: inline-block;
to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox. I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.
Cheers,
Richard Stamper |
|
Re: Dropdown boxes and Moptions, posted by Stefan Ritt on Mon Jun 15 16:44:35 2009
|
| Arno Teunisse wrote: |
|
Hello
I have a config file :
Attributes = Author, Author Email, Category, Customer, server,HPSD_ID, Cust_ID ,Subject , Change Window
; which fields will be shown !!
List display = ID,Author, Category, Customer, server, HPSD_ID, Cust_ID,Subject , Change Window
Type Change Window = datetime
# Type Change Window End = datetime
Options Category = Network , Server ,
Options Customer = Arag{A}, Frieslandbank{B}, Super de Boer{C}, NRE{D}
{A} Options server = arag-lin1,arag-lin2,arag-lin3,arag-lin4, arag-lin5, arag-lin6, arag-lin7
{B} Options server = rc1upas02, rc1upas22,rc1upas03,rc1upas04,rc1uptsm01,rc1upas07,rc1upas08
{C} Options server = xia61031,xia61032 ,xia61033,xia61034,xia61035,xia61036,xia61037,xia61038,xia61039,xia61040,xia61032 ,xia61033,xia61034,xia61035,xia61036,xia61037,xia61038,xia61039,xia61040
{D} Options server = server27,server32,server34 ,server37,server38,server40
Extendable options = Category , Customer,server
Required Attributes = server , customer, Subject, Change window Begin , Change Window End
This works OK, However when I change the {A} Options to {A} Moptions in the above code i get an error which tells me that a required field is not selected. So, with the pull down it works, with Moptions ( select boxes ) it will say that a required field is not selected. Any hints ?
regards Arno
|
Thanks for reporting this bug. I fixed it in SVN revisoin 2213. |
|