I have a scenario where I need to redirect a WebRes with some additional headers. Once I add the headers to the response, I then call the res.redirect method but the headers added are not sent with the redirect or at least not received at the redirection end point. In an attempt to figure this out, I tried to examine the source and find almost nothing to look at more than just a reiteration of the documentation.

**
** Send a redirect response to the client using the specified status
** code and url.  If this response has already been committed this
** method throws an Err.  This method implicitly calls `done`.
**
abstract Void redirect(Uri uri, Int statusCode := 303)

I seem to stumble into this scenario a lot in fantom when examining the source code in such that there is no source code to examine.

So two questions:

1. How do I get a WebRes redirection to respect headers added to it?
2. More of a general question but using this specific method as a basis of an example, where does the source code really live when fantom docs show this as the source?

Hi jhughes - looking at the source often helps, so good for you for trying!

In this instance, web::WebRes is a mixin, also known as an interface in other other languages. In this instance, the default implementation is in wisp - so the source you're after is: wisp::WispRes.

As for your particular problem of headers in re-directs, I don't see why they're not received by the client. But the client may ignore them when re-directing. See How to forward headers on HTTP redirect

I was reading up on redirect headers and this almost always seems to be a client issue so I was already working on doing something similar to that forum post.

Going back to the first link where the source code is, how would I even know that? Searching for WispRes doesn't really turn up anything useful and i'm not even sure i've ever seen any mention of anything other than a WebRes in any of the documentation.

You can think of the web pod as the standard, the wisp server / pod would then be the implementation. If you know Java, then it's similar to there being a Java Servlet standard and Tomcat or Jetty being the implementation.

As to how you're supposed to know the link between the two... well, you're right in that I don't think it's documented anywhere. I think I initially guessed the relationship myself.

But thankfully, I think this is the only scenario where the definition and implementation are in different pods.

where does the source code really live

If you are looking at classes in the core sys pod, then all the implementation is native. So taking sys::Log as an example, you'll find:

• <FAN_HOME>/src/sys/fan/Log.fan

But this is the Fantom definition / documentation, the actual implementation is native to Java or Javascript, so you'll need to look here:

• <FAN_HOME>/src/sys/java/fan/sys/Log.fan
• <FAN_HOME>/src/sys/js/Log.js

Any method from any other pod that is marked with the keyword native also does not have a Fantom implementation, so again, you'll have to look for the Java / JS implementation. Taking native dom::Win class as an example, you'll find:

• <FAN_HOME>/src/dom/fan/Win.fan
• <FAN_HOME>/src/dom/js/Win.js

I'd say anytime you are working with an abstract class and want to know the specific implementation being used, the easiest way is to just dump it (whether its Java, C#, Fantom, etc):

Void onService(WebReq req, WebRes res)
{
  echo("My req type is: $req.typeof")
  ....
}

I guess this just feels like, for me at least, that there is a break in the documentation/source code chain.

I've come across this scenario in more than just this one instance (WispReq would be in the same boat as the WispRes for instance) but there's obviously some backing code somewhere that's just not available to the fantom website but it exists in fantom. So every time there's a native method that i'm looking into, i have to track down the file from the repository or local src folders instead of just having that source code and/or documentation also available in the documentation section of fantom or even a link to the backing code.

The discovery of WispReq and WispReq, both fantom classes, being unavailable anywhere in the fantom documentation leads me to believe that there's even more missing classes since I would expect all fantom classes in the current build would be available unless there's some sort of selective process happening filtering things out.

i have to track down the file from the local src folders

Yes. As you note, the API Source links on the Fantom website don't always tell the whole story.

unless there's some sort of selective process filtering things out (of the documentation)

Correct, there is. If you look at the WispReq and WispRes classes you'll note that they're labelled as internal, as in internal to the pod. Internal classes represent the inner workings of the pod and so are purposely not exposed or listed in the documentation.

Take my Sizzle library for instance, that has one public class in the API, but the source code actually contains ten classes. But the user never sees them or interacts with them, they're for Sizzle's use only. So I've marked them as internal. Generally I find this of great benefit to Fantom, for when looking at libraries in Java land I often find 100s of classes, leaving me bamboozled as to how or where I start using it!

So to recap, any class that is internal or annotated with the @NoDoc facet does not make it to the documentation.

$ grep -rn ": WebReq" .
./doc/docIntro/doc/ChangeLog.fandoc:274:- #1862: WebReq.locales
./wisp/fan/WispReq.fan:15:internal class WispReq : WebReq

Not many substitutes for just cloning the repo -- and digging into the code ;)