assembly cgi program printing garbage
 

I have this old assembly program (nasm64) that does a good job of comparing strings in a particular way outside of CGI and I am trying to make it work as a CGI. It works correctly from the CLI but prints the typical square black boxes and question marks as a CGI (through a HTML/browser-document and Apache2), this string of garbage is always proportional to the length of the strings tested, so it is trying to print the string. In my test, ASCII strings are used but the program is intended to be used for true (non-ascii) utf-8 strings.

The same code in BASIC works perfectly (ascii tested again although the result should be the same with UTF-8 on a byte-by-byte comparison basis) but can't get the length given by CGI variable of the returned strings (how many bytes to read) and is too slow at string comparisons.
I have insufficient experience in C, Perl, PHP or Python etc and only a basic knowledge of Apache2 and this strings comparison is a real bottleneck in need of assembly code that I find is my fastest way of solving that sort of problems.

My questions are: What should I be looking for to solve the problem? Is Apache2 mis-configured/not-configured? I thought it was configured for UTF-8 by default and should automatically print through system call 1 (write) anything printable. Or could it be a GDM3 problem? Or a combination of both? Or do I miss something?

I assume the same code in C would give the same result so a solution for C would probably solve the problem in Assembly code.

Thank you for your help.

Unmodified Debian 7 and Apache2 from DVD installation.
New Gigabyte mobo AB350 with Feb 2017 BIOS.

You forgot to attach the relevant code, also the problematic output.

Are you printing the correct HTTP headers including Content-Type, Content-Length, etc.

If you're using UTF-8, you should send Content-Type: text/html; charset=utf-8 or Content-Type: text/plain; charset=utf-8

Apache is generally not configured for UTF-8 by default. Supplying the charset as Laserbeak mentioned would change it for that page.

You do understand that your CGI script needs to supply HTML output in order to be viewed in a browser. At a very minimum, it needs to send
as the first thing...the blank line is significant. It should also send:
where ... represents the output of the CGI and whatever HTML formatting might be also required...although only the meta tag is required to address your question. Please let us know how that works for you.

And to repeat NevemTeve's question...may we see the code and the output, please?

Thank you for the answers. My apologies, I was wrongly convinced it was so simple I did not think code was necessary, I also have to do this from the local library.
note: tried mov rdx, [sometextLen] - no good either

result through browser in asm
result through CLI in asm

result through browser with C
result through CLI with C
In nasm (version coming with Debian 7)
makes if freeze, I'll try to specify UTF-8 in the 'meta' line as suggested.

How about sending 'HTTP/1.0 200 OK' first?

That comes from Apache in response to a request. It doesn't need to be programmed in the CGI program/script.

To me, it looks like Apache is simply outputting the binary instead of executing it.

https://httpd.apache.org/docs/2.4/howto/cgi.html

That's an excellent point!! I hadn't considered it because my CGI scripts are always plain text (perl) files, so when that happens to me it's very obvious.

rblampain, please show us how you are calling your program from the web page.

Edit: I just remembered why that happens. (tho I just saw that this is in the link Guttorm posted) The setting
in httpd.conf needs to include the suffix of the file to be executed, so if its .asm - add that to the AddHandler directive. Otherwise, apache doesn't know to execute the code, and just delivers it instead.

That is probably the problem. But I wouldn't add .asm to CGI programs, just assemble it to a binary ending in .cgi.

Good point. The OP probably already has a binary; it just needs to be renamed as something.cgi.

Sorry, I get caught up in the "root cause" and forget the simple solutions -- making the solution fit the conditions instead of 'tother way 'round...I also forget that some people might not have access to the httpd.conf

Also, make sure it's in the right "cgi-bin" directory/folder.

This is incorrect. If you send "Content-Type: text/plain" in the header, any browser will just display it as plain text. You do not have to send HTML.

So this is only DOS/Windows compatible? I tried to assemble it and it wouldn't run. When I ran "file" on it, it said "COM executable for DOS".

Yes, that's true. Point is that the first thing from the script needs to be a "Content-Type:..." header followed by a blank line. If that's not present, the browser will report an error 500:
(this example is a script without the header so the first thing it sends is the <html> tag)

Yep! But you made it sound like you HAD to send text/html. Just pointing that out... no prob.

> I tried to assemble it and it wouldn't run.
How did you try to assemble it? What command did you use?

Among others (including yasm)... this seemed most promising but it still didn't run:

results:

This is for Mac OS X:


LOL I can almost run it this way, but it's in reverse order:

The source code explicitly says "ELF entry point" but this is Mach-O. If I tried it on Solaris that uses ELF format binaries, it'd probably work fine.

I compiled it in Solaris:

???

I would try link it:

This did work as far as I came up with an executable but it ran and didn't print anything out at all and I just returned to the prompt. Perhaps it went to some log somewhere?

It did not work for Mac OS X replacing -f elf64 with -f macho64 though

Works for me:

I did not try to add any extension in the linker command but in theory, the server does not need one. "document root" and "cgi-bin" directories have been left as per original default Debian 7 (no need for added "exec .extension" or "alias .." since whatever is in that directory is considered by Apache2 to be cgi executable)

This code does not call the server and also work in my case
but the funny thing is that, calling the server through html submit, itdoes not work in C either even though gcc has no complaint about the source code, doing the same thing in "YABASIC" with two "print" statements in the code (one to screen and the other to file) does not print correctly to the screen (possibly not at all, I cannot remember) altough printing to file shows the correct output (6 'variable name=value' blocks), not code. So it apears that the garbage printed is not code but the correct output (always proportional to the string used) that for some reason Apache2 cannot render correctly. Since the browser is UTF-8 by default which YASM does not understand (although the data is temporarily ASCII only), perhaps, not printing to screen in YABASIC had to be expected so I did not worry too much about that.
I have used verbatim a more involved example from the NCSA (32bit) and it does not work either - same result.

Works for me:

I'm sorry, but that is not correct. The server does need an extension which matches one of the values in AddHandler in the httpd.conf file.
Without a matching extension, apache will not execute the script/program, but will just send the contents of the file, which in your case, is a binary file.

Please add a .cgi extension to your compiled file and try again. I don't believe it needs to be re-compiled with the extension, the file just has to have that name for apache to execute it instead of delivering it.

I believe if it is in a designated cgi-bin directory the web server should try to execute the file and if that fails for some reason (anything from not being able to execute it at all to returning no header or a bad header) it should just give a server error. It shouldn't send the contents of the file, which means wherever the file was, it wasn't in a properly declared cgi-bin directory.

As a last straw, one could check log-files access_log and error_log in directory /var/log/apache2

I stand corrected. It appears I've been very lazy and have just been applying the directive to directories containing executable scripts rather than creating ScriptAlias for them. When doing that, the directive is also required.

When a ScriptAlias directive is defined for a folder, then neither of the other directives are required.

I believe I'll do some tweaking of the config file over the next couple of days. Thank you, Laserbeak and NevemTeve :hattip:

rblampain, what I've been saying will work, it's just not the only way, and probably not the best way. Please confirm that your cgi-bin does have a ScriptAlias defined for it. Something like:
...and I would not expect that to be provided by default,because the realname directory needs to be specified. There may be a default example commented out:
(which I copied from my current httpd.conf -- which is why I need to use the other two directives :rolleyes:

I cannot understand what the problem was. Initially having "charset=urf-8" (maybe not the exact spelling) in the header seemed to make it worse, so I took it out on the assumption that I only had ascci in the testing files. In my last test, I put that back and it works and I have no idea what the difference is. There was no need to alter any configuration, as explained in my previous post.