Root > Integral parts > Options > Dialogs page > WEB


Previous pageReturn to chapter overviewNext page   

This is setup options for WEB dialog (edtWEB). They are located at Dialogs tab.



WEB dialog options


Note: error messages in dialogs are controlled by nested exceptions behaviour options.


1. "HTTP Error Code" (.WebErrorCode) option specifies value of HTTP Status Code to be returned to client's web browser when exception is occurred.


Most typical values are either 200 (default) or 500:

200 status code means success/OK, and it is a usual status code to be returned to client when web application produces content page without any error. Use this status code to produce error message as normal web pages.
500 error code means internal server error, and it is a typical error code to be returned when something goes wrong with web application. Use this or any other error code to indicate failure to client's web browser.


Important note: some web application implementations (server or browser) may ignore actual page content for status codes like 500 error code. This means that customized HTML page (see "HTML layout" option below) will be ignored. Use 200 status code for such cases.


Note: not all web application supports returning custom status code for error page. Support for this feature depends on used framework, its version and its configuration.



2. "HTML layout" (.HTMLLayout) option specifies an HTML page template to be send to client in case of error during its request's processing. E.g. this is an error HTML page. You can put any text here, the resulting page will be exactly the same as you specified here. You can customize error HTML page to match your web-site.


While web dialog is designed for HTML, but you may also use a simple JSON or XML instead of HTML. For example:












<?xml version="1.0" encoding="<%CODE_PAGE%>" standalone="yes" ?>
<!DOCTYPE ...optional... >

    <exception id="<%BUG_ID%>">


See also: using web dialog for custom web API.


The target text's encoding is determinated by meta "content-type" HTML tag (note "charset=UTF-8" in the example below):



   <meta http-equiv="content-type" content="TEXT/HTML; charset=UTF-8" />



or by corresponding XML header (note "encoding" in the example below):


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>


Code page name can be anything supported by the host OS. For example: UTF-8, iso-8859-1, Windows-1252, windows-1251 or even UTF-16, UTF-16BE, unicode or unicodeFFFE. See this list of supported encodings for Windows platform. We recommend to use UTF-8 when possible. Alternatively, you may use <%CONTENT_TYPE%>/<%CODE_PAGE%> tags (see below) to use encoding from your web framework (defined by framework's Response / Reply objects).



It's a good idea to use either <%CONTENT_TYPE%>/<%CODE_PAGE%> (see below) or a fixed UTF-8 encoding;
If you specify fixed encoding - then dialog will adjust HTTP headers as needed;
If encoding is missing in HTML page template - then dialog will use encoding from Response object. If it's missed too - then dialog will use UTF-8 as default;
Old Delphi versions supports only ANSI encodings. So even if you specify one of unicode encodings (like UTF-8 or any other) - you will be able to show only characters in current code page (even though result page will be properly encoded in unicode). You won't be able to use full range of unicode and mix, say, Latin, Japanese and Cyrillic in the same text.



Page customization via tags

You can also use some special tags, which looks like this: <%TAG%>. If you insert such tag in template's text, it will be replaced with actual value at run-time. There is a hint for common used tag right at dialog's settings page.


Note: tags are case-insensitive.


Supported tags:




This tag is replaced with Response.ContentType property. Use this tag in <head> part to indicate proper encoding. You can enter fixed meta "content-type" HTML tag or you can use <%CONTENT_TYPE%> to indicate current encoding.




   <meta http-equiv="content-type" content="text/html; charset=UTF-8" />


Note that <%CONTENT_TYPE%> is expanded to full meta content HTML tag, not just to "charset=X" part. If you need to add codepage to non-HTML content - use <%CODE_PAGE%> tag instead (see below).




This tag is replaced with code page name, extracted from Response.ContentType property.







EurekaLog Documentation

It's standard error caption for error dialogs. It can be customized on localization page. Usually it's used in <title> HTML tag, but it actually can be used anywhere.




Error occurred




It's class name of exception object. It can be used anywhere.








It's exception message. It can be used anywhere.




Access violation at address 0216942E in module 'ISAPI.dll'. Write of address 00000000




This is a short textual description for exception address. Indicates point of exception's raising. It can be used anywhere.




(000D842E){ISAPI.dll   } [0216942E] MainISAPI.Error (Line 41, "MainISAPI.pas") + $2




This is Bug ID value from bug report. It's extremely useful to identify a problem in bug report file. Can be used anywhere.






We recommend that you use the following model in the production for security reasons: don't expose any information on error page, place only a generic message like:


<p>The server application has encountered an error with <b><%BUG_ID%> code</b>. We're sorry for any inconveniences.</p>

<p>Please, <a href="">contact server's administrator</a>.</p>


You can analyze full bug report from logs (bug report file) - as administrator.


Note: even if you don't specify this tag anywhere - dialog will automatically append a hidden comment to page's source with Bug ID's value.


For example:


    ... (other page content)



<!-- EurekaLog page ID: CC2F96D8 -->

<!-- EurekaLog Bug ID: 824B0000 -->


Page ID is just a random number to distinct one page from another. Bug ID is Bug ID's value.




This is a compact form of call stack from bug report. Can be useful for quick diagnostic. It's highly recommended to hide this information in release version of your application for security reasons. The call stack is wrapped in <pre> HTML tag, so it can be used only inside <body> HTML tag.





 - ISAPI.dll.MainISAPI.Error,41[4]

 - ISAPI.dll.MainISAPI.GoToError,82[1]

 - ISAPI.dll.MainISAPI.RaiseException,87[1]

 - ISAPI.dll.MainISAPI.TModule.Action,97[5]

 - ISAPI.dll.HTTPApp.TWebActionItem.DispatchAction

 - ISAPI.dll.HTTPApp.TCustomWebDispatcher.DispatchAction

 - ISAPI.dll.HTTPApp.TCustomWebDispatcher.HandleRequest

 - ISAPI.dll.HTTPApp.TDefaultWebAppServices.InvokeDispatcher

 - ISAPI.dll.HTTPApp.TDefaultWebAppServices.HandleRequest

 - ISAPI.dll.WebReq.TWebRequestHandler.HandleRequest

 - ISAPI.dll.ISAPIApp.TISAPIApplication.HttpExtensionProc

 - ISAPI.dll.ISAPIApp.HttpExtensionProc




Full file name to bug report file. Can be used anywhere.








Full bug report enclosed in <pre> HTML tag.


WARNING: never show this information in production for security reasons.




<pre>EurekaLog alpha 1 RC 




  1.1 Start Date      : Fri, 15 Apr 2011 22:34:24 +0359

  1.2 Name/Description: w3wp.exe - (IIS Worker Process)

  1.3 Version Number  : 7.5.7601.17514

  1.4 Parameters      : -m 0 -t 20

  1.5 Compilation Date: Sat, 30 Dec 1899 00:00:00 +0359

  1.6 Up Time         : 10 minute(s), 7 second(s)




  2.1 Date          : Fri, 15 Apr 2011 22:44:32 +0359

  2.2 Address       : 0236942E

  2.3 Module Name   : ISAPI.dll

  2.4 Module Version: 

  2.5 Type          : EAccessViolation

  2.6 Message       : Access violation at address 0236942E in module 'ISAPI.dll'. Write of address 00000000

  2.7 ID            : 7D390000

  2.8 Count         : 1

  2.9 Status        : New

  2.10 Note         : 


... (other information in bug report - cut for compactness)


00D3EFF4: 00000000   023694FE: FF C3 E9 FF CA F2 FF EB F0 8D 45 E8 50 A1 70 DB  ..........E.P.p.

00D3EFF8: 00000000   0236950E: 37 02 89 45 E0 C6 45 E4 00 8D 55 E0 33 C9 B8 DC  7..E..E...U.3...

00D3EFFC: 00D3F018   0236951E: 95 36 02 E8 92 43 F5 FF 8B 45 E8 B9 4C 00 00 00  .6...C...E..L...





This is obsolete tag used only for backward compatibility. Do not use it in new applications.



See also:

WEB dialog for general description of this dialog's type

Send feedback... Build date: 2022-03-28
Last edited: 2019-03-27
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: