Re: "errorfile 503" doesn't appear to be working

[Shawn Heisey]

On 6/22/2016 7:41 PM, Michael Ezzell wrote:
> On Jun 22, 2016 7:06 PM, "Shawn Heisey"  > wrote:
> >
> > I have verified that there is nothing on the line after the headers.  On
> > the recommendation I saw elsewhere, the file is in DOS text format, so
> > each line ends in CRLF, not just LF.  Could the line endings be the
> problem?
>
> Most definitely.
>
> Review the file's content with a hex editor or hexdump.
>
> Each line of headers *must* end with \r\n which is 0x0d 0x0a (CR,
> LF).  This file is used as a raw HTTP response, and the Chrome error
> suggests strongly that this is your problem, or this:
>
> After the last header, you *must* have two sets of of those, e.g.:
>
> HTTP/1.0 503 Service Unavailable [0d][0a]Content-Type:
> text/html[0d][0a]Cache-Control: no-cache [0d][0a]Connection:
> close[0d][0a][0d][0a]...
>
> After that point, you're in the body, so pretty much anything goes,
> just keep the whole thing under 16K.
>
> Definitely don't count on an indicator of "file format" to prove that
> this is correct.
>
> Copy one of the other files and edit with vim.  You'll see the ^M in
> the headers, which of course is the same as \r.  The \n doesn't show
> in vim since that's the normal newline.

I do all my config editing in vim.  It doesn't show ^M -- it just adds
[dos] to the status line, to indicate that the line endings are not
standard.  I have seen ^M in my editor before -- I wonder if maybe I was
using nvi or vim-tiny rather than the full vim on those occasions.

Using hexedit revealed a problem that vim hid from me -- there was a
single space on what I thought was a blank line, so after the last
header, the hex was 0D 0A 20 0D 0A.

I fixed this in my file by removing the space, and when we can get the
client to allow us another testing window, I will give it another try. 
Hopefully everything will work.

As usual, Chrome and Firefox are handling my mistake according to what
the standards actually state, and IE ignores all the rules.

Thank you for the pointers!

Shawn

Re: "errorfile 503" doesn't appear to be working

[Michael Ezzell]

My previous post included a couple of spurious spaces after a couple of the
header values.  Corrected here:

HTTP/1.0 503 Service Unavailable[0d][0a]Content-Type:
text/html[0d][0a]Cache-Control: no-cache[0d][0a]Connection:
close[0d][0a][0d][0a]...

Side note: be sure your body is at least 512 bytes, passing it with  or equivalent wording consistent with local policy :) to
disable the ridiculous friendly messages in at least some versions of IE:
http://stackoverflow.com/a/11544049/1695906


On Jun 22, 2016 9:41 PM, "Michael Ezzell"  wrote:
>
>
> On Jun 22, 2016 7:06 PM, "Shawn Heisey"  wrote:
> >
> > I have verified that there is nothing on the line after the headers.  On
> > the recommendation I saw elsewhere, the file is in DOS text format, so
> > each line ends in CRLF, not just LF.  Could the line endings be the
problem?
>
> Most definitely.
>
> Review the file's content with a hex editor or hexdump.
>
> Each line of headers *must* end with \r\n which is 0x0d 0x0a (CR, LF).
This file is used as a raw HTTP response, and the Chrome error suggests
strongly that this is your problem, or this:
>
> After the last header, you *must* have two sets of of those, e.g.:
>
> HTTP/1.0 503 Service Unavailable [0d][0a]Content-Type:
text/html[0d][0a]Cache-Control: no-cache [0d][0a]Connection:
close[0d][0a][0d][0a]...
>
> After that point, you're in the body, so pretty much anything goes, just
keep the whole thing under 16K.
>
> Definitely don't count on an indicator of "file format" to prove that
this is correct.
>
> Copy one of the other files and edit with vim.  You'll see the ^M in the
headers, which of course is the same as \r.  The \n doesn't show in vim
since that's the normal newline.

Re: "errorfile 503" doesn't appear to be working

[Michael Ezzell]

On Jun 22, 2016 7:06 PM, "Shawn Heisey"  wrote:
>
> I have verified that there is nothing on the line after the headers.  On
> the recommendation I saw elsewhere, the file is in DOS text format, so
> each line ends in CRLF, not just LF.  Could the line endings be the
problem?

Most definitely.

Review the file's content with a hex editor or hexdump.

Each line of headers *must* end with \r\n which is 0x0d 0x0a (CR, LF).
This file is used as a raw HTTP response, and the Chrome error suggests
strongly that this is your problem, or this:

After the last header, you *must* have two sets of of those, e.g.:

HTTP/1.0 503 Service Unavailable [0d][0a]Content-Type:
text/html[0d][0a]Cache-Control: no-cache [0d][0a]Connection:
close[0d][0a][0d][0a]...

After that point, you're in the body, so pretty much anything goes, just
keep the whole thing under 16K.

Definitely don't count on an indicator of "file format" to prove that this
is correct.

Copy one of the other files and edit with vim.  You'll see the ^M in the
headers, which of course is the same as \r.  The \n doesn't show in vim
since that's the normal newline.

Re: "errorfile 503" doesn't appear to be working

[Shawn Heisey]

On 6/22/2016 12:45 AM, Jarno Huuskonen wrote:
> On Tue, Jun 21, Shawn Heisey wrote:
>> When I take down the back end server and make a request, I get the
>> browser's standard unavailable page, I do not see the custom page I
>> defined.  Have I done something wrong?
> 
> With "browser's standard unavail. page" do you mean IE with it's
> "helpful" error messages ?

I used chrome.  Didn't try other browsers.

> Does your logs(w/out the "no log" option) show that "be-stg-spark-443"
> returns 503 (and I guess you can compare the custom page filesize with
> log entry) ?

The size of the response in the logs indicate that the file IS being sent.

I changed the first line of the file so it gave a 404 response instead
of 503.  This did NOT work in any browser I tried: Chrome, IE, and Firefox.

When I changed the response code to 200, it started working in IE, but
not Chrome or Firefox.  Because virtually all of the clients out there
are most likely using IE, this is probably good enough ... but I was
really hoping that I could retain a response code indicating an error
response.

Do I need to do something special so that a custom page shows up in all
browsers *without* returning a 200 code?

This is the result in IE with the code set to 200:

https://www.dropbox.com/s/qzvq1dveujtipp5/spark-unavailable-IE-200.png?dl=0

Chrome has always thought the headers were truncated and shows this:

https://www.dropbox.com/s/m02bthxtnk5oiba/spark-unavailable-chrome-200.png?dl=0

When I check firebug in firefox, it shows the 200 response, but no body.

Do I need additional headers in the errorfile?  This is the first part
of that file's contents:

=
HTTP/1.0 200 OK
Cache-Control: no-cache
Connection: close
Content-Type: text/html


=

I have verified that there is nothing on the line after the headers.  On
the recommendation I saw elsewhere, the file is in DOS text format, so
each line ends in CRLF, not just LF.  Could the line endings be the problem?

Thanks,
Shawn

Re: "errorfile 503" doesn't appear to be working

[Jarno Huuskonen]

Hi,

On Tue, Jun 21, Shawn Heisey wrote:
> When I take down the back end server and make a request, I get the
> browser's standard unavailable page, I do not see the custom page I
> defined.  Have I done something wrong?

With "browser's standard unavail. page" do you mean IE with it's
"helpful" error messages ?

Do you get custom page with wget/curl ?

Does your logs(w/out the "no log" option) show that "be-stg-spark-443"
returns 503 (and I guess you can compare the custom page filesize with
log entry) ?

-Jarno

-- 
Jarno Huuskonen