Author Archives: paulkmoore

Date and time regexs

Posted on by
Reply

Sometimes you just want to grab a period of event information from a logfile, or similar.

I should probably turn this into a regex generator of some description, but, in the meantime, here are some examples of how you can grep out time ranges from ISO 8601 timestamped entries e.g. 2018-11-04T11:34:05Z

Note: I’m sure some will point out that the ‘correct’ solution to this problem is to convert the strings to datetime objects and then select from linear ranges; this is not that solution.

Specific day

grep -E '2018\-11\-04'

Note: the escaped hyphen separator

Specific hour

grep -E '2018\-11\-04T11'

Spanning hours

Include 11:00 and 12:00

grep -E '2018\-11\-04T1[1-2]'

Range of minutes (simple)

11:03-11:06 inclusive

grep -E '2018\-11\-04T11\:0[3-6]'

Range of minutes (less simple)

11:34-11:44; we have to deal with the range as an option as it spans the 10’s of minutes boundary

grep -E '2018\-11\-04T11\:(3[4-9]|4[0-4])'

Range of minutes (complex)

11:55-12:05; a more complex range including minutes and hours

grep -E '2018\-11\-04T(11\:5[5-9]|12\:[0-5])'

Note: we could also write this as:

grep -E '2018\-11\-04T1(1\:5[5-9]|2\:[0-5])'

but I think the first form is more clear in its intent – never a bad thing with regexes!

 

 

 

REST gems

Posted on by
Reply

The following snippets represent little gems of knowledge in my journey of understanding RESTful architectures.

Hopefully, you’ll find them useful.

Roy Fielding

The following are clarifications that Roy has made with respect to RESTful design.

Failure to use HTTP (methods)

During the design of the Atom media type, Roy challenges the use of a link with a rel(ationship) of ‘edit‘.  His point is that one only needs a resource (URL) and the HTTP verb PUT in order to support the use case i.e. editing.

Whatever happened to the idea that Atom was based on REST principles
of resources that have identifiers which a client could apply a
method to and see if that method worked by looking at the response?

Any notion of a linked resource to enable editing has fallen outside of HTTP design and hence isn’t RESTful.

Atom doesn’t need rel=”edit” or rel=”editcontent” or app:edit-content.

Note: when first investigating REST, I researched existing media types heralded as RESTful for inspiration.  The learning point here is that there is a good deal of work branded as RESTful that frankly isn’t, caveat emptor.

Definition of ‘self-descriptive’

In Roy’s dissertation we learn that REST constrains messages to be ‘self-descriptive’, however, the dissertation is not very explicit about what this means.  Whilst there is coverage in the use of MIME types and other HTTP headers, all of which contribute to the ‘self-descriptiveness’ I still struggled with this until I ran across this post in [rest-discuss]:

Self-descriptive means that the type is registered and
the registry points to a specification and the specification explains
how to process the data according to its intent.

So, ‘self-descriptive’ means that the exchange uses a (preferably registered) media type and that the ‘other headers’ in Section 6.3 are used appropriately.

As a counterpoint, it is worth taking a moment to consider other (non-RESTful) interpretations of self-descriptive.  These are primarily schema based specifications e.g. JSON Schema, XML etc. This is not to say that such approaches are ‘bad’ (for some definition of bad) but that they use a separate layer of indirection to describe the data content. For example, the XML specification does not define the data elements of the exchange, only how to encode them,  and therefore the message in not self-descriptive in the RESTful sense. To understand the message requires XML and some further (app-specific) specification of how XML is being used in that exchange.

You can of course, decide that you’re going to do things your own way:

If you only use HTTP in an APP-specific way, then all you get is one
application. If you use HTTP the way it was designed to be used,
then everyone else’s work on HTTP will be available to you. That is
what REST is all about: engineering for serendipity.

For later

Caching and authentication:

http://tech.groups.yahoo.com/group/rest-discuss/message/11476

Resources should not be typed:

http://tech.groups.yahoo.com/group/rest-discuss/message/11224

Resource types – revisit this:

Re: [rest-discuss] Terminology: “Resource Types”?

Representation format in URL or Query String or Conneg:

http://tech.groups.yahoo.com/group/rest-discuss/message/11153

Roy’s definition of “self-descriptiveness” = ‘in the a registered media type’

  1. http://tech.groups.yahoo.com/group/rest-discuss/message/6594

http://www.imc.org/atom-protocol/mail-archive/msg03925.html

Caching and authentication:

http://tech.groups.yahoo.com/group/rest-discuss/message/11476

Resources should not be typed:

http://tech.groups.yahoo.com/group/rest-discuss/message/11224

Resource types – revisit this:

Re: [rest-discuss] Terminology: “Resource Types”?

Representation format in URL or Query String or Conneg:

http://tech.groups.yahoo.com/group/rest-discuss/message/11153

Elastic Load Balancer support in Wildfly 8.x

Posted on by
Reply

Background

I am working on a Java EE project using Wildfly 8.x that will be deployed to Amazon Web Services behind an Elastic Load Balancer (ELB) instance.  Additionally, the ELB will handle the SSL encryption/decryption i.e. SSL offload.

Used in this manner, the ELB adds useful information to the HTTP request in the form of “X-Forwarded-*” headers – see the ELB documentation for full details.

Of particular note is the “X-Forwarded-Proto” header which identifies the originating protocol (scheme), in our case this contains “https” for all requests where the ELB is providing the SSL offload.

Issue

The issue here is how to make the Wildfly (actually Undertow) environment aware that it should use the header to determine the originating protocol.  As of Wildfly 8.0.0.CR1 this is included, but finding documentation about how to configure it was non-trivial.

Solution

Essentially, what you need to do is to enable “proxy-address-forwarding” for your (undertow) server in the Wildfly configuration.  Note: I’ll be considering the “default server” here only.

There are multiple ways to achieve this, but the simplest is just to add the proxy-address-forwarding="true" attribute to the http-listener in your standalone.xml or domain.xml, as below:

<server name="default-server">
    <http-listener name="default" socket-binding="http" proxy-address-forwarding="true"/>
    <host name="default-host" alias="localhost">
        <location name="/" handler="welcome-content"/>
        <access-log prefix="access"/>
    </host>
</server>

Or, for a bit of automation, you could use the the CLI against your running instance:

$JBOSS_HOME/bin/jboss-cli.sh --connect --command="/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding, value=true)"

For those interested in understanding the source code, check out the io.undertow.server.handlers.ProxyPeerAddressHandler class here.

Outcome

The result of this is that calls to HttpServletRequest.getScheme() will return “https” for requests that have had the SSL offloaded by the ELB. Nice.

And now HttpServletRequest.isSecure() returns as expected as well.