Same reason https://foo.example/bar/baz.html exposes it - it tells the web server which file to access. Cool, customized routing wasn't always a thing.
IIS, Apache HTTPd, and Nginx have supported rewrite rules with wildcards and regex since forever.
Thus, there's no absolute rule that serving a static state must faithfully map to filesystem representation except convenience. Nor, do dynamic requests need to map to include the details of dynamic handler URIs unless the application cannot change generated links.
Revealing backend state, while somewhat Security Through Obscurity (STO)(TM), it's unwise to volunteer extraneous information without a purpose. Preferably, some other simple, one-way hash external representation should be used.
I played client-side Netscape JS and Apache HTTPd CGI bash shell scripts (not even Perl) to write a toy multiuser chat app in 1996. IIRC, it used a primitive form of long polling where it kept an HTTP/0.9 session open with keepalive commands periodically and then broadcasted the message received to all other users who were also connected.
mod_rewrite came out in 1997, which was quite early but still after eBay launched. IIS didn’t get built-in support for URL rewriting until 2008. nginx didn’t even exist until 2004.
C++ compiler errors back in C++99/01 days weren't usually so bad unless you were doing basic code and not some SFINAE shit. Increased boost usage and C++11 introduced var-arg templates and a lot of other things that made things explode.
Today we've removed a lot of SFINAE magic since if-constexpr that is easier to read/trace and also the existence of CONCEPTS to pre-constrain to compatible types and thus avoiding implementation details from becoming the error.
True, on the other hand writing portable code was a mess, even if we constrained ourselves to UNIX world, as each vendor compiler supported a different flavour of the standard.
I had some fun between HP-UX aC, AIX xlC, Solaris cc, and Red-Hat gcc, and naturally there was MSVC as well.
We had #ifdefs in place for prototypes, because the version of the aC compiler we had on our development server still only supported K&R C function definitions.
Not really, there is a reason why the Java pivot into the server during the early's 2000's, it wasn't only Sun, IBM, Oracle, Bea marketing, it was definitly much better experience than mod_tcl or mod_perl without JTI[0], CGI/ISAPI in C or C++.
Likewise with ASP.NET on Windows land, as ASP with VB, and C++ alongside COM wasn't that great either.
[0] - By the time this started to matter Java 1.3 was already the common version.
At the time that would have required that they write a custom proxy that sat in front of IIS and everyone would have been very confused about why you even wanted to do that. IIS (and every other web server in 1996) just took the URL, converted it to a path, and ran that, with no transformations applied. This was three years into the web and many things that are simple and obvious now were not back then.
Yeah, IIS didn't have any sort .htaccess type thing for url routing IIRC. Even later on, we had to dig under the hood of asp.net because we didn't want .aspx in our paths.
Yeah, it's a module in Apache too, it just comes OOB, so 'LAMP' had a cheap routing/rewrite solution. (ASP.net had APIs for that kind of stuff, so that was probably MS's original answer.)
.html is less problematic than .dll, since the served file IS html, regardless of how you generate it. In an ideal world you could just fetch baz.json and get to the intended API.
Same reason https://foo.example/bar/baz.html exposes it - it tells the web server which file to access. Cool, customized routing wasn't always a thing.
The eBay example, by the way, is ISAPI, not CGI.
IIS, Apache HTTPd, and Nginx have supported rewrite rules with wildcards and regex since forever.
Thus, there's no absolute rule that serving a static state must faithfully map to filesystem representation except convenience. Nor, do dynamic requests need to map to include the details of dynamic handler URIs unless the application cannot change generated links.
Revealing backend state, while somewhat Security Through Obscurity (STO)(TM), it's unwise to volunteer extraneous information without a purpose. Preferably, some other simple, one-way hash external representation should be used.
I played client-side Netscape JS and Apache HTTPd CGI bash shell scripts (not even Perl) to write a toy multiuser chat app in 1996. IIRC, it used a primitive form of long polling where it kept an HTTP/0.9 session open with keepalive commands periodically and then broadcasted the message received to all other users who were also connected.
It's always been technically possible to make URLs look how you want but it wasn't always in vogue.
And in eBay's specific case they may have opted against due to the performance challenges URL rewriting may have involved.
mod_rewrite came out in 1997, which was quite early but still after eBay launched. IIS didn’t get built-in support for URL rewriting until 2008. nginx didn’t even exist until 2004.
eBay architecture slides from 2006: https://www.cs.cornell.edu/courses/cs330/2007fa/slides/eBayS...
3.3M LoC C++, that must have been quite painful.
They replaced it with Java, which was probably worse. :p
No. At least, not nearly as many footguns. Also, compiler error messages that actually can be deciphered.
C++ compiler errors back in C++99/01 days weren't usually so bad unless you were doing basic code and not some SFINAE shit. Increased boost usage and C++11 introduced var-arg templates and a lot of other things that made things explode.
Today we've removed a lot of SFINAE magic since if-constexpr that is easier to read/trace and also the existence of CONCEPTS to pre-constrain to compatible types and thus avoiding implementation details from becoming the error.
True, on the other hand writing portable code was a mess, even if we constrained ourselves to UNIX world, as each vendor compiler supported a different flavour of the standard.
I had some fun between HP-UX aC, AIX xlC, Solaris cc, and Red-Hat gcc, and naturally there was MSVC as well.
We had #ifdefs in place for prototypes, because the version of the aC compiler we had on our development server still only supported K&R C function definitions.
Not really, there is a reason why the Java pivot into the server during the early's 2000's, it wasn't only Sun, IBM, Oracle, Bea marketing, it was definitly much better experience than mod_tcl or mod_perl without JTI[0], CGI/ISAPI in C or C++.
Likewise with ASP.NET on Windows land, as ASP with VB, and C++ alongside COM wasn't that great either.
[0] - By the time this started to matter Java 1.3 was already the common version.
That's not really an explanation. Could be named https://foo.example/bar/baz as well.
I also used to ask myself why they would expose the filename of the DLL.
At the time that would have required that they write a custom proxy that sat in front of IIS and everyone would have been very confused about why you even wanted to do that. IIS (and every other web server in 1996) just took the URL, converted it to a path, and ran that, with no transformations applied. This was three years into the web and many things that are simple and obvious now were not back then.
Yeah, IIS didn't have any sort .htaccess type thing for url routing IIRC. Even later on, we had to dig under the hood of asp.net because we didn't want .aspx in our paths.
It definitly could have it, provided someone wrote an ISAPI extension/filter combo for it.
I got to know, because I wrote a complete proxy on top of ISAPI, with callback handlers that could be written in C or Tcl.
On Windows NT and 2000, for our application server based on top of IIS (we had a version on top of Apache as well).
Yeah, it's a module in Apache too, it just comes OOB, so 'LAMP' had a cheap routing/rewrite solution. (ASP.net had APIs for that kind of stuff, so that was probably MS's original answer.)
I believe it was Windows Server 2008 that brought URL rewriting support to IIS.
But by then ebay wouldn’t be using ISAPI :)
.html is less problematic than .dll, since the served file IS html, regardless of how you generate it. In an ideal world you could just fetch baz.json and get to the intended API.